184 lines
7.7 KiB
Plaintext
184 lines
7.7 KiB
Plaintext
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
|