Subversion Repositories Kolibri OS

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 :  "\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 :  \unzip.exe -qt tes.zip         (testing performance)

              \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