For an introduction to this discussion, see http://www.gnashdev.org/wiki/index.php/NinjaProfile
I feel uncomfortable *discussing* in the Wiki, so I do it here. Ok, since there are 18,5 million calls to read_uint() it's no wonder it's slow. First, it causes some million calls to read_byte() which in the end means the equal number of calls to fread() with 1 byte counts (in case of a local file). Maybe it would be better to implement a internal buffered memory stream (sort of a read-ahead buffer for the "stream" class. The latter would also allow faster bit-reading operations when mapping the first two/four bytes of the buffer as a 16/32 bit unsigned integer and just shifting as needed (instead of ORing and LOOPing). Of course, that would depend on the host byte order. Secondly, the read_uint() function masks the used bits after having consumed them: m_current_byte &= ((1 << (m_unused_bits - bits_needed)) - 1); Maybe it would be faster to leave m_current_byte as-is and mask the needed bits when updating "value". Should avoid a write access to memory and we don't need masking at all in the "consume all the unused bits" case. Setting m_current_byte = 0 should be unnecessary, too. And instead of setting bits_needed = 0 a "break" would do as well (ok, not very nice, but sligtly faster). Udo BTW, we have another "tu_xxxxx" with "tu_file"... _______________________________________________ Gnash-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnash-dev
