Path: utzoo!utgpu!utstat!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!HTIKUB5.BITNET!KOLB From: KOLB@HTIKUB5.BITNET Newsgroups: comp.sys.ibm.pc Subject: pk(un)zip Message-ID: Date: 22 Feb 89 21:55:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Lines: 75 hi, now that Phil Katz' new non-ARC compression program (PKZ090.EXE in SIMTEL's PD1: directory) is out, people might be interested in a first evaluation. After a few days of playing around with it (including transfer of more than 100 ARC-files to ZIP-files) I got the following impression. 1. PKZIP in default mode ("shrinking") is about as fast PKPAK/PKARC, mostly insignificantly slower, sometimes slitely faster. 2. The ZIP-files produced in default mode were overall slitely smaller than the corresponding ARC-files produced by PKPAK/PKARC. Big files compressed even considerably better than under PKarc, small binaries were about the same, and small ASCII-files did slitely worse. 3. The extended compression option of PKZIP works like a charm on binaries. Even level one (50% slower than default mode) produces ZIP-files considerably smaller than files produced by NoGate's PAK--at not much more than half the time. And there lay worlds between the filesizes of a PAK-file and a ZIP-file produced by level 4 (at about the same speed). 4. On ASCII-files, however, the extended option is a mixed blessing: At least level 1 seems to consistently produce bigger ZIP-files than the default method. On not too big files some level will eventually reach and eventually undercut the size of the NoGate-PAK-file (PAK is not very efficient on small ASCIIs anyway), but the generalization seems to be: The bigger an ASCII-file is, the bigger the overhead of the extended option--up to the point where even level 4 produces bigger ZIP-files than the default method. Fortunately the modes can (in fact, have to) be specified seperately for binary and ASCII files. 5. Extraction times are about the same as for PKPAK/PKARC (slitely better for files compressed with the extended method), and about 3 times as fast as NoGate's PAK. Some examples: (time_needed/Size_of_compressed_file) Small Binaries Big Binaries Small ASCII BIG ASCII (66 COM/EXE files) (2 EXE files) (40 C-sources) (1 text file) 1003527 bytes 360224 bytes 540531 bytes 643437 bytes PKPAK/PKARC 1:44/731868 0:58/390219 0:48/242499 0:49/289800 NoGate PAK 4:42/674216 2:35/354061 1:56/240153 2:15/256231 PKZIP (default) 1:46/731595 1:02/381819 0:51/244284 0:55/264638 PKZIP -e?1 3:05/640774 1:39/331441 1:44/253859 1:47/291901 PKZIP -e?2 3:16/632277 1:40/322148 1:46/241161 1:49/275310 PKZIP -e?3 3:42/624898 1:44/315122 1:53/228533 1:56/264278 PKZIP -e?4 4:44/620614 1:58/311045 1:58/220348 2:18/255922 Just to illustrate my point (4), here are the figures for a huge textfile (942449 bytes): PKPAK/PKARC 1:16/468810 NoGatePAK 3:31/420028 PKZIP(def) 1:23/431879 PKZIP -ea4 3:20/431919 To summarize: PKZIP in default mode is every bit as fast and efficient as the defunct PKPAK/PKARC, and that means, clearly superior to the infamous SEA-products. If time is not all that important, the extended mode is a beauty for binary files. My own compromise between speed and size is PKZIP -eb3 meaning: extended method level 3 for binaries, default mode for ASCII. Overall, I think, Phil Katz and the others did a beautiful job on this new program. I, myself, will most certainly switch to PKZIP and I'm happy that the reasons for that don't have to be purely "moral". (just transforming my ARC-files to ZIP-files gave me another 1.5MB of free space). P.S.: I have no connection whatsoever with PKWARE Inc. or anyone else in this business. (In fact, I didn't even pay my registration yet...) ------------------------------------------------------------------------- hans-peter kolb, Tilburg University, Holland kolb@htikub5.bitnet