0,0 → 1,183 |
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 |