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