[Zlib-devel] crc32 big/little endian

[John Bowler]

From: Mark Adler
>My assumption was the embedded developers are much more likely
>to rip into the zlib source and squeeze out exactly what they
>need and no more, whereas the big system developers just want
>to use zlib as is, and want it to be fast with no concern for
>memory usage at the scale of zlib.

You may be right, but the embedded developers have little choice if they face memory issues other than to re-code.

>From what I've seen both groups tend to just use the code as-is, if they can (and it's a testament to the quality of the code how often they can.)

>If space is really more important than speed, then I could come
>up with a space-optimized version of zlib based on puff, a scaled-down
>deflate, and the short versions of adler32 and crc32, and leave out the
>rest of the stuff.

I guess the real point is that the size (text+data) of 'example' decreases by 15% if I define NOBYFOUR (x86, gcc 3.4.4. -Os).  Knowing how to select the small code is likely to the biggest win (i.e. benefit the most people.)

>From my point of view I know that zlib accounts for the most time in almost all practical uses of libpng, so speed is apparently important, but it's actually much more important to have something that is tractable.  If something starts out small I know that code size isn't the problem and any profiling I do is more meaningful as a result.

In other words, it's easier to optimize for a particular platform from small well written code than it is from equally well written code optimized for a different platform.  Size optimization works on every platform.

Still, the thing that potentially helps me most is the existence of puff - since I know how the buffering works in libpng puff gives me the freedom to experiment with different ways of managing the window.

John Bowler <jbowler at acm.org>