Date: Wed, 27 Mar 1996 01:31:50 CET +0100
From: Christian Spieler (IKDA, THD, D-64289 Darmstadt)
Subject: More detailed comparison of MSDOS Info-ZIP programs' performance
Hello all,
In response to some additional questions and requests concerning
my previous message about DOS performance of 16/32-bit Info-ZIP programs,
I have produced a more detailed comparison:
System:
Cx486DX-40, VL-bus, 8MB; IDE hard disk;
DOS 6.2, HIMEM, EMM386 NOEMS NOVCPI, SMARTDRV 3MB, write back.
I have used the main directory of UnZip 5.20p as source, including the
objects and executable of an EMX compile for unzip.exe (to supply some
binary test files).
Tested programs were (my current updated sources!) Zip 2.0w and UnZip 5.20p
- 16-bit MSC 5.1, compressed with LZEXE 0.91e
- 32-bit Watcom C 10.5, as supplied by Kai Uwe Rommel (PMODE 1.22)
- 32-bit EMX 0.9b
- 32-bit DJGPP v2
- 32-bit DJGPP v1.12m4
The EMX and DJ1 (GO32) executables were bound with the full extender, to
create standalone executables.
A) Tests of Zip
Command : "<system>\zip.exe -q<#> tes.zip unz/*" (unz/*.* for Watcom!!)
where <#> was: 0, 1, 6, 9.
The test archive "tes.zip" was never deleted, this test
measured "time to update archive".
The following table contains average execution seconds (averaged over
at least 3 runs, with the first run discarted to fill disk cache);
numbers in parenteses specify the standard deviation of the last
digits.
cmpr level| 0 | 1 | 6 | 9
===============================================================
EMX win95 | 7.77 | 7.97 | 12.82 | 22.31
---------------------------------------------------------------
EMX | 7.15(40) | 8.00(6) | 12.52(25) | 20.93
DJ2 | 13.50(32) | 14.20(7) | 19.05 | 28.48(9)
DJ1 | 13.56(30) | 14.48(3) | 18.70 | 27.43(13)
WAT | 6.94(22) | 8.93 | 15.73(34) | 30.25(6)
MSC | 5.99(82) | 9.40(4) | 13.59(9) | 20.77(4)
===============================================================
The "EMX win95" line was created for comparison, to check the performance
of emx 0.9 with the RSX extender in a DPMI environment. (This line was
produced by applying the "stubbed" EMX executable in a full screen DOS box.)
B) Tests of UnZip
Commands : <system>\unzip.exe -qt tes.zip (testing performance)
<system>\unzip.exe -qo tes.zip -dtm (extracting performance)
The tes.zip archive created by maximum compression with the Zip test
was used as example archive. Contents (archive size was 347783 bytes):
1028492 bytes uncompressed, 337235 bytes compressed, 67%, 85 files
The extraction directory tm was not deleted between the individual runs,
thus this measurement checks the "overwrite all" time.
| testing | extracting
===================================================================
EMX | 1.98 | 6.43(8)
DJ2 | 2.09 | 11.85(39)
DJ1 | 2.09 | 7.46(9)
WAT | 2.42 | 7.10(27)
MSC | 4.94 | 9.57(31)
Remarks:
The executables compiled by me were generated with all "performance"
options enabled (ASM_CRC, and ASMV for Zip), and with full crypt support.
For DJ1 and DJ2, the GCC options were "-O2 -m486", for EMX "-O -m486".
The Watcom UnZip was compiled with ASM_CRC code enabled as well,
but the Watcom Zip example was made without any optional assembler code!
Discussion of the results:
In overall performance, the EMX executables clearly win.
For UnZip, emx is by far the fastest program, and the Zip performance is
comparable to the 16-bit "reference".
Whenever "real" work including I/O is requested, the DJGPP versions
lose badly because of poor I/O performance, this is the case especially
for the "newer" DJGPP v2 !!!
(I tried to tweak with the transfer buffer size, but without any success.)
An interesting result is that DJ v1 UnZip works remarkably better than
DJ v2 (in contrast to Zip, where both executables' performance is
approximately equal).
The Watcom C programs show a clear performance deficit in the "computational
part" (Watcom C compiler produces code that is far from optimal), but
the extender (which is mostly responsible for the I/O throughput) seems
to be quite fast.
The "natural" performance deficit of the 16-bit MSC code, which can be
clearly seen in the "testing task" comparison for UnZip, is (mostly,
for Zip more than) compensated by the better I/O throughput (due to the
"direct interface" between "C RTL" and "DOS services", without any mode
switching).
But performance is only one aspect when choosing which compiler should
be used for official distribution:
Sizes of the executables:
| Zip || UnZip
| standalone stub || standalone | stub
======================================================================
EMX | 143,364 (1) | 94,212 || 159,748 (1) | 110,596
DJ2 | 118,272 (2) | -- || 124,928 (2) | --
DJ1 | 159,744 | 88,064 || 177,152 | 105,472
WAT | 140,073 | -- || 116,231 | --
MSC | 49,212 (3) | -- || 45,510 (3) | --
(1) does not run in "DPMI only" environment (Windows DOS box)
(2) requires externally supplied DPMI server
(3) compressed with LZexe 0.91
Caveats/Bugs/Problems of the different extenders:
EMX:
- requires two different extenders to run in all DOS-compatible environments,
EMX for "raw/himem/vcpi" and RSX for "dpmi" (Windows).
- does not properly support time zones (no daylight savings time)
DJv2:
- requires an external (freely available) DPMI extender when run on plain
DOS; this extender cannot (currently ??) be bound into the executable.
DJv1:
- uses up large amount of "low" dos memory (below 1M) when spawning
another program, each instance of a DJv1 program requires its private
GO32 extender copy in low dos memory (may be problem for the zip
"-T" feature)
Watcom/PMODE:
- extended memory is allocated statically (default: ALL available memory)
This means that a spawned program does not get any extended memory.
You can work around this problem by setting a hard limit on the amount
of extended memory available to the PMODE program, but this limit is
"hard" and restricts the allocatable memory for the program itself.
In detail:
The Watcom zip.exe as distributed did not allow the "zip -T" feature;
there was no extended memory left to spawn unzip.
I could work around this problem by applying PMSETUP to change the
amount of allocated extended memory to 2.0 MByte (I had 4MB free extended
memory on my test system). But, this limit cannot be enlarged at
runtime, when zip needs more memory to store "header info" while
zipping up a huge drive, and on a system with less free memory, this
method is not applicable, either.
Summary:
For Zip:
Use the 16-bit executable whenever possible (unless you need the
larger memory capabilities when zipping up a huge amount of files)
As 32-bit executable, we may distribute Watcom C (after we have confirmed
that enabling ASMV and ASM_CRC give us some better computational
performance.)
The alternative for 32-bit remains DJGPP v1, which shows the least problems
(to my knowledge); v2 and EMX cannot be used because of their lack of
"universality".
For UnZip:
Here, the Watcom C 32-bit executable is probably the best compromise,
but DJ v1 could be used as well.
And, after all, the 16-bit version does not lose badly when doing
"real" extraction! For the SFX stub, the 16-bit version remains first
choice because of its much smaller size!
Best regards
Christian Spieler