pkopp@potpourri.UUCP (Paul Kopp) (06/28/88)
As usual, our site didn't receive all the binaries. Would someone out
there *please* send me parts 3 and 4 of the recently posted PKARC 3.6.
Thanks!!!!
-------------------------------------
Paul Kopp The opinions (if any) expressed
Gould Inc., Computer Systems Division are my own.
Fort Lauderdale, Florida
Mail paths?, oh yea mail paths: ...!{sun,uunet,pur-ee,brl-bmd}!gould!pkopp
...!{ihnp4!codas,allegra}!novavax!gould!pkoppKOLB@HTIKUB5.BITNET (02/23/89)
hi,
now that Phil Katz' new non-ARC compression program (PKZ090.EXE in
SIMTEL's PD1:<MSDOS.ZIP> 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.bitnetkluge@lan.informatik.tu-muenchen.dbp.de (Oliver Kluge) (03/15/89)
In article <KPETERSEN.12477289400.BABYL@WSMR-SIMTEL20.ARMY.MIL> KOLB@HTIKUB5.BITNET writes: [Some very interesting "benchmark" figures about PAK, PKARC and ARC had to be deleted due to size reduction (compression?).] >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...) But now another question arises: What about compatibility????? I already have PKARC, and PKZIP seems to be better, but will it uncompress .ARC-Files?? ARC is still the standard! If PKZIP isn't able to read - if not write - .ARC-Files, this means I have to keep SEA's ARC (or the old PKARC) together with PKZIP in order to be able to read stuff from colleagues or the net! Perhaps the author of the above could say a word or two about this topic. Thanx! So long ... :-) Oliver -- TTTU MMMMM kluge%lan.informatik.tu-muenchen.dbp.de@relay.cs.net (CS-NET, ARPA) T U U M M Oliver Kluge, Parallel Computing Lab, \ unido.UUCP (UUCP) T U M M M Technical University Munich, Arcisstr. 21, 8000-Munich 2, W. Germany T UUU M M "Why stop now just when I'm hating it?" Marvin, the paranoid android