[Zlib-devel] infnew-5b available for testing

[Greg Roelofs]

> If you have gzip, I would like to see comparison of ung with it.  
> inflateBack(), used by ung, was written to replace the version of 
> inflate used by gzip.

Okey dokey:

>> meltdown:/util/compression/zlib-1.1.4-infnew 324> time ./ung-static < /backups/quantum-TM3200A-archive.tgz > /dev/null
>> 11.000u 1.090s 0:15.58 77.5%    0+0k 0+0io 92pf+0w
>> 11.260u 0.830s 0:15.35 78.7%    0+0k 0+0io 92pf+0w
>> 11.030u 1.020s 0:15.35 78.5%    0+0k 0+0io 92pf+0w
>> 10.830u 1.160s 0:15.16 79.0%    0+0k 0+0io 92pf+0w
>> 10.850u 1.250s 0:15.43 78.4%    0+0k 0+0io 92pf+0w
                  0:15.374

>> meltdown:/util/compression/zlib-1.1.4-infnew 329> time ./ung-static -t /backups/quantum-TM3200A-archive.tgz 
>> 10.830u 1.280s 0:15.41 78.5%    0+0k 0+0io 92pf+0w
>> 10.790u 1.150s 0:15.43 77.3%    0+0k 0+0io 92pf+0w
>> 10.720u 1.200s 0:15.52 76.8%    0+0k 0+0io 92pf+0w
>> 11.140u 0.980s 0:15.45 78.4%    0+0k 0+0io 92pf+0w
>> 11.030u 1.090s 0:15.52 78.0%    0+0k 0+0io 92pf+0w
                  0:15.466

meltdown:/util/compression/zlib-1.1.4-infnew 408> time gzip -dc < /backups/quantum-TM3200A-archive.tgz > /dev/null
16.160u 1.150s 0:21.29 81.3%    0+0k 0+0io 99pf+0w
16.320u 1.010s 0:21.12 82.0%    0+0k 0+0io 99pf+0w
16.390u 0.970s 0:21.23 81.7%    0+0k 0+0io 99pf+0w
16.110u 1.200s 0:21.18 81.7%    0+0k 0+0io 99pf+0w
16.150u 1.090s 0:21.25 81.1%    0+0k 0+0io 99pf+0w
               0:21.214

meltdown:/util/compression/zlib-1.1.4-infnew 413> time gzip -t /backups/quantum-TM3200A-archive.tgz 
16.330u 0.930s 0:21.19 81.4%    0+0k 0+0io 98pf+0w
16.000u 1.030s 0:20.82 81.7%    0+0k 0+0io 98pf+0w
16.210u 1.080s 0:21.18 81.6%    0+0k 0+0io 98pf+0w
16.140u 1.040s 0:21.09 81.4%    0+0k 0+0io 98pf+0w
16.170u 0.950s 0:21.14 80.9%    0+0k 0+0io 98pf+0w
               0:21.084

So a 27% improvement in wallclock time on a relatively unloaded 1.4 GHz
Linux box with 256 MB RAM (recall that the archive is 313 MB, so it doesn't
fit in the Linux cache/buffers).  Btw, I use wallclock these days since it
accounts for things like inefficiencies in I/O vs. CPU vs. memory, etc.
But you can tot up the user and system numbers yourself, if you like.


>> One big wishlist item for a near-future zlib beta, however:  a better 
>> configure script. The current one blows big-time;

> We'll see if Jean-loup chimes in on this issue.  I'm certainly willing 
> to include a new one, but I'll need help testing it and refining it for 
> various environments.  This could potentially be a can of worms ...

Most of the hard work is already done; if any particular system already
supports both static and shared libraries, this doesn't change any of that--
it just does both at the same time.  And since configure doesn't do all
that much, the main work is simply in rearranging the stuff the final sed
block modifies.  The only new features to the script would be to allow both
-shared and -static options simultaneously and to modify the LIBS variable
to have two parts most of the time, one part if shared libs aren't supported.
The rest is already there (in configure and in the combined makefile I sent).

Btw, I mention this because I know what the chances of Jean-loup actually
doing it are, and I was hoping to avoid doing it myself. :-)  Gotta go
look for jobs today, sigh.

Greg