roelofs@nas.nasa.gov (Cave Newt) (05/19/91)
This is a message I posted internally to the Info-ZIP group; it was
suggested to me that perhaps people here might be interested as well.
If not...don't blame me. :-)
Greg
P.S. Those wishing to join the Info-ZIP group may do so by sending a
message to Info-ZIP-Request@WSMR-Simtel20.Army.Mil (Yet Another
Alias for Keith Petersen). I assume y'all are aware of this, but
just in case...
_____________
Subject: comparisons IV
Greetings, gentlebeings...
Things have been moving pretty quickly on the compression front (that's
like a shock front, except different) lately, so I thought it was high
time for another look at the data I posted back in February (and December
and November).
This update includes both VAX and PC comparisons. Once again, the test
file was 500k of old info-zip messages, sans uuencoded stuff. All the
byte sizes given below refer to the total archive size; in the case of
the zipfiles, this includes 116 bytes of header info.
VAX 11/780, 4.3BSD results:
498.0u 16.3s 10:55 78% 85+585k 181+251io 18pf+0w (zip082) 204824 bytes
476.5u 22.2s 11:57 69% 89+831k 206+270io 31pf+0w (zip08) 209012 bytes
806.0u 38.0s 31:05 45% 81+429k 271+344io 2pf+0w (zip07) 212198 bytes
791.8u 13.5s 15:10 88% 86+429k 194+292io 30pf+0w (zip07 -i) 212198 bytes
790.6u 44.4s 21:09 65% 64+425k 209+302io 2pf+0w (zip05) 220314 bytes
350.1u 24.2s 23:18 26% 55+233k 106+125io 1pf+0w (lharc) 224879 bytes
39.6u 2.3s 2:33 27% 23+845k 66+ 44io 2pf+0w (compress) 245059 bytes
125.4u 5.7s 8:16 26% 46+229k 109+110io 2pf+0w (zip04 -s) 261928 bytes
112.7u 4.1s 6:56 28% 51+318k 76+ 86io 2pf+0w (zoo) 286873 bytes
175.5u 13.1s 11:47 26% 65+200k 134+127io 3pf+0w (arc) 301996 bytes
-- -- -- -- -- -- -- (nothing) 500459 bytes
So speed has improved by close to 40% and compression by another couple
percent. (zip082 refers to Jean-loup's announced-but-unposted improvements
to the implosion code.)
16MHz 386 PC [that's a REAL 386, not one of them puss SX's :-) ], MS-DOS +
MSC 6.0 results:
tim zip082 -b f: test unzip3.p6 135.39 sec 204824 bytes (5)
tim zip08 -b f: test unzip3.p6 155.11 sec 209012 bytes (8)
tim arj200 a -mj -wf: test unzip3.p6 51.08 sec 180260 bytes (1)
tim arj200 a -wf: test unzip3.p6 39.82 sec 190313 bytes (2)
tim arj200 a -m2wf: test unzip3.p6 34.00 sec 194953 bytes (3)
tim lha210 a /wf: test unzip3.p6 48.66 sec 200707 bytes (4)
tim arj200 a -m3wf: test unzip3.p6 33.23 sec 208211 bytes (6)
tim pkzip110 -bf: test unzip3.p6 32.91 sec 208952 bytes (7)
tim lharc113 a -wf: test unzip3.p6 50.81 sec 224896 bytes (9)
tim arj200 a -m4wf: test unzip3.p6 30.92 sec 229930 bytes (10)
tim compress430 -c unzip3.p6 > f:test.Z 20.55 sec 247180 bytes (11)
tim pkarc360 -bf: -a test unzip3.p6 11.15 sec 281452 bytes (12)
tim zoo201 a test c:unzip3.p6 24.82 sec 286998 bytes (13)
[zoo test was from f: drive]
Clearly assembly language in critical places makes a big difference in
execution time, but we're all aware of that. What most impressed me was
the big lead ARJ has over everybody else (including LHA, which I had be-
lieved was comparable). ARJ's level-3 mode appears to sort of a PKZIP
compatibility mode; the next two levels are only slightly slower but
compress quite a bit better, and the top level is far and away superior
to everybody else. Of course, it only exists under MS-DOS, too.
Jean-loup's recent zip tweaks boost zip to the number-three position,
comfortably above PKZIP; even the almost-stock 0.8 version (I removed the
MSDOS ifdef in implode.c to allow 8K dictionaries) is pretty much neck-
and-neck with PKWare's version. 0.82 uses the small memory model and,
for this test, the default stack size of 2048 bytes (0.80 == compact + 32K
stack). Both were LZEXE'd (none of the other executables was), and they
give the same results as the VAX versions, which is sort of reassuring.
Timewise, PKARC stands out, but so does its compression (in another way...
:-) ). Compress and zoo also do pretty well, but likewise at a cost.
Other factors: doing everything on the RAM disk saves about 3.5 seconds,
but it wasn't possible in many of the tests (and was therefore not done at
all); LZEXEing may have saved between .25 and 1.25 seconds on the zip tests
(results varied); and "tim" is a little utility I picked up which approxi-
mates the Unix "time" command and which is probably only accurate to the
nearest tenth of a second...but I didn't feel like repeating all these tests
five times to find out for sure.
Well, there you have it. Tune in again in about 3 months for the next
exciting installment...
Greg