1Date: Wed, 27 Mar 1996 01:31:50 CET +0100 2From: Christian Spieler (IKDA, THD, D-64289 Darmstadt) 3Subject: More detailed comparison of MSDOS Info-ZIP programs' performance 4 5Hello all, 6 7In response to some additional questions and requests concerning 8my previous message about DOS performance of 16/32-bit Info-ZIP programs, 9I have produced a more detailed comparison: 10 11System: 12Cx486DX-40, VL-bus, 8MB; IDE hard disk; 13DOS 6.2, HIMEM, EMM386 NOEMS NOVCPI, SMARTDRV 3MB, write back. 14 15I have used the main directory of UnZip 5.20p as source, including the 16objects and executable of an EMX compile for unzip.exe (to supply some 17binary test files). 18 19Tested 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) 22- 32-bit EMX 0.9b 23- 32-bit DJGPP v2 24- 32-bit DJGPP v1.12m4 25 26The EMX and DJ1 (GO32) executables were bound with the full extender, to 27create standalone executables. 28 29A) Tests of Zip 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". 34 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 38 digits. 39 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 =============================================================== 50 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.) 54 55 56B) Tests of UnZip 57 Commands : <system>\unzip.exe -qt tes.zip (testing performance) 58 <system>\unzip.exe -qo tes.zip -dtm (extracting performance) 59 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 63 64 The extraction directory tm was not deleted between the individual runs, 65 thus this measurement checks the "overwrite all" time. 66 67 | testing | extracting 68 =================================================================== 69 EMX | 1.98 | 6.43(8) 70 DJ2 | 2.09 | 11.85(39) 71 DJ1 | 2.09 | 7.46(9) 72 WAT | 2.42 | 7.10(27) 73 MSC | 4.94 | 9.57(31) 74 75Remarks: 76 77The executables compiled by me were generated with all "performance" 78options enabled (ASM_CRC, and ASMV for Zip), and with full crypt support. 79For DJ1 and DJ2, the GCC options were "-O2 -m486", for EMX "-O -m486". 80 81The Watcom UnZip was compiled with ASM_CRC code enabled as well, 82but the Watcom Zip example was made without any optional assembler code! 83 84 85 86Discussion of the results: 87 88In overall performance, the EMX executables clearly win. 89For UnZip, emx is by far the fastest program, and the Zip performance is 90comparable to the 16-bit "reference". 91 92Whenever "real" work including I/O is requested, the DJGPP versions 93lose badly because of poor I/O performance, this is the case especially 94for the "newer" DJGPP v2 !!! 95(I tried to tweak with the transfer buffer size, but without any success.) 96An interesting result is that DJ v1 UnZip works remarkably better than 97DJ v2 (in contrast to Zip, where both executables' performance is 98approximately equal). 99 100The Watcom C programs show a clear performance deficit in the "computational 101part" (Watcom C compiler produces code that is far from optimal), but 102the extender (which is mostly responsible for the I/O throughput) seems 103to be quite fast. 104 105The "natural" performance deficit of the 16-bit MSC code, which can be 106clearly seen in the "testing task" comparison for UnZip, is (mostly, 107for 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 109switching). 110 111But performance is only one aspect when choosing which compiler should 112be used for official distribution: 113 114Sizes of the executables: 115 | Zip || UnZip 116 | standalone stub || standalone | stub 117====================================================================== 118EMX | 143,364 (1) | 94,212 || 159,748 (1) | 110,596 119DJ2 | 118,272 (2) | -- || 124,928 (2) | -- 120DJ1 | 159,744 | 88,064 || 177,152 | 105,472 121WAT | 140,073 | -- || 116,231 | -- 122MSC | 49,212 (3) | -- || 45,510 (3) | -- 123 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 127 128Caveats/Bugs/Problems of the different extenders: 129 130EMX: 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) 134 135DJv2: 136- requires an external (freely available) DPMI extender when run on plain 137 DOS; this extender cannot (currently ??) be bound into the executable. 138 139DJv1: 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 143 "-T" feature) 144 145Watcom/PMODE: 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. 151 In detail: 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. 160 161Summary: 162 163For Zip: 164Use the 16-bit executable whenever possible (unless you need the 165larger memory capabilities when zipping up a huge amount of files) 166 167As 32-bit executable, we may distribute Watcom C (after we have confirmed 168that enabling ASMV and ASM_CRC give us some better computational 169performance.) 170The 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 172"universality". 173 174For UnZip: 175Here, the Watcom C 32-bit executable is probably the best compromise, 176but DJ v1 could be used as well. 177And, 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 179choice because of its much smaller size! 180 181Best regards 182 183Christian Spieler 184