Re[2]: [Gnash-dev] Re: Bitwise stream reading performance

[Udo Giacomozzi]

Hello strk,

Tuesday, August 28, 2007, 10:50:56 AM, you wrote:
s> The avantage is giving stream users the choice of wheter to do
s> memory or stream reads.

Ok, I try to summarize what I mean now:

The "stream" class knows the size of a TAG, right? So it could load
into memory the whole tag (unless direct access is desired).

I don't expect anything larger than 64k so no big deal. And even if,
we could still optimize that.

Having the TAG in memory makes bit reading much easier. No fiddling
with bytes, just simple boundary checking *once* in read_bits().

Reading of the bits could be even something like this (simplified, no
checks):


unsigned int read_bits(int bits_to_read) {

  unsigned int* bytes = *data + bit_position / 8;

  // *bytes now is a 32 bit value containing all bits we need
  // but this simplified example can't handle bits_to_read > 24

  return (*bytes) >> (bit_position % 8);

  bit_position += bits_to_read;

}


*data is the buffer pointing to the complete in-memory TAG.
The division and modula will be optimized by the compiler to shifts
and ANDs, so they're pretty fast.

Now this assumes that the SWF byte order matches the host byte order
(does it match Intel byte order?). We will need specialized versions
for different byte orders (hosts) for sure. I hope it matches at least
Intel byte order.

Anyway, you get the idea. See why I think a extra class is
unnecessary?


Are there TAGs that mix bit reading *and* byte chunks? If so (assuming
byte chunks are always byte-aligned):

void read_bytes(char buffer*, size_t count) {

  unsigned offset = (bit_position+7) / 8;

  memcpy(buffer, data + offset, count);

  bit_position = (offset + count) * 8;

}


Note the functions above are just intended to explain my idea and of
corse are simplified.

Udo