Our bloat problem

Posted Aug 5, 2005 19:56 UTC (Fri) by roelofs (guest, #2599)
In reply to: Our bloat problem by dmantione
Parent article: Our bloat problem

Also don't forget the small ones, libpng is over 200kb on my system, just to interpret some metadata grouped into fourcc chunks. This exclusive decompression,

That's a rather simplistic view. libpng supports 19 pixel formats, depth-scaling, a moderately complex 2D interlacing scheme, alpha compositing, CRC verification, and various other transformations and ancillary bits. It also includes row-filtering, which is a fundamental component of the compression codec. I won't defend everything that's gone into libpng, but it's highly misleading to refer to all of it as bloat. If libpng (or a higher-level library built on top of it) didn't include it, all of your PNG-supporting applications would have to.

that is in libz (better, 80kb, but I remeber Pkzip being 30kb on my MS-Dos system).

Your memory is slightly faulty there. PKZIP 2.04g was 42166 bytes, and if all you care about is compressing your files, I can do far better with my 3712-byte trunc utility--and at 100% compression, too! But if you'd actually like to decompress them again someday, you'd better add PKUNZIP 2.04g, which rang in at 29378 bytes. IOW, the PKWARE codec was 71544 bytes (plus a number of other standalone utilities), while my copy of libz.so.1.2.3 is 71004 bytes--and 1.2.2 was 66908 bytes. Keep in mind also that significant parts of PKZIP and PKUNZIP were written in assembler, which, though capable of producing much smaller binaries, is generally not considered by most of us to be the most productive or maintainable of programming languages. (And, btw, libpng includes additional MMX assembler code for decoding row filters and for expanding interlace passes.)

I'm sure the Commodore Amiga was able to read iff files (on which png is based) in less code.

PNG was not based on IFF. The gross structure may have been suggested by someone familiar with IFF, but IFF itself was considered and rejected as a basis for PNG.

Greg

Our bloat problem

Posted Aug 6, 2005 11:22 UTC (Sat) by dmantione (guest, #4640) [Link] (1 responses)

In other words, it is bloat. All that people want fom libpng is read and
write png files and I doubt it is being used for more than that in the
majority of situations.

I know the differences between iff and png. I'd say png is even easier to
read than iff.

libraries

Posted Aug 12, 2005 14:03 UTC (Fri) by ringerc (subscriber, #3071) [Link]

Actually, as far as I know a well written lib won't have much non-read-only static data (so it can be shared efficiently), and should incur only a very small memory overhead for any unused portions. If I recall correctly unused parts of the library aren't even read from disk.

There are many things to complain about with shared libraries, but their on-disk size is not one of them unless you're building embedded systems. If you are, you can build a cut down version of most libraries quite easily.