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