tt3x@vax5.cit.cornell.edu (03/19/90)
Did anyone read the latest copy of BYTE magazine and their article on file compressors/decompressors? I find it strange that the author of that article claims that PKZIP 1.02 is by far the most efficient and fastest compressor available. From my experiences, PKZIP may be fast but it is definitely not the most efficient. It seems as though LHarc 1.13C (despite what the article claims and shows) produces smaller files the majority of the time. I don't know about the credibility of such tests but I've done a lot of PKZIPS and LHarcs and LHarcs seem more efficient despite its speed that most people don't like (it doesn't affect me because I have a 25 mhz 386). What have your experiences been? Bobby Li Internet: TT3X@VAX5.CIT.CORNELL.EDU
kdq@demott.COM (Kevin D. Quitt) (03/20/90)
I'm running a 386/25 or 386/33, and I have ea4 and eb4 set in my
environment to guarantee maximum compression by pkzip. If I'm
compressing, I'm not generall in that mush of a hurry. Two or three
extra compression seconds can save a minute or two of transmission time
at 19.2K.
I was not particularly impressed with LHarc's compression, when
compared to pkzip's maximum.
kdq
--
Kevin D. Quitt Manager, Software Development
DeMott Electronics Co. VOICE (818) 988-4975
14707 Keswick St. FAX (818) 997-1190
Van Nuys, CA 91405-1266 MODEM (818) 997-4496 Telebit PEP last
34 12 N 118 27 W srhqla!demott!kdq kdq@demott.com
"Next time, Jack, write a God-damned memo!" - Jack Ryan - Hunt for Red OctoberRalf.Brown@B.GP.CS.CMU.EDU (03/20/90)
In article <3657.26037c1b@vax5.cit.cornell.edu>, tt3x@vax5.cit.cornell.edu wrote: }seems as though LHarc 1.13C (despite what the article claims and shows) }produces smaller files the majority of the time. I don't know about }the credibility of such tests but I've done a lot of PKZIPS and LHarcs }and LHarcs seem more efficient despite its speed that most people }don't like (it doesn't affect me because I have a 25 mhz 386). In my experience, LHarc produces smaller archives when there are lots of little files, while PKZIP produces smaller archives when there are only a few large files in the archive. For example, compressing my current copy of the Interrupt List (a single text file of 652,503 bytes) produces a 182,373-byte .LZH and a 166,570-byte .ZIP. In general however, the difference between PKZIP, NoGate's PAK v2.x and LHARC is only a few percent, and which one wins depends mainly on the size and contents of the files being placed in the archive. PKZIP has a disadvantage on archives containing many small files because of its greater per-file overhead (storing two copies of the housekeeping information). -- UUCP: {ucbvax,harvard}!cs.cmu.edu!ralf -=- 412-268-3053 (school) -=- FAX: ask ARPA: ralf@cs.cmu.edu BIT: ralf%cs.cmu.edu@CMUCCVMA FIDO: Ralf Brown 1:129/46 "How to Prove It" by Dana Angluin Disclaimer? I claimed something? 16. proof by cosmology: The negation of the proposition is unimaginable or meaningless. Popular for proofs of the existence of God.
cs4g6ag@maccs.dcss.mcmaster.ca (Stephen M. Dunn) (03/21/90)
In article <3657.26037c1b@vax5.cit.cornell.edu> tt3x@vax5.cit.cornell.edu writes:
$ Did anyone read the latest copy of BYTE magazine and their
$article on file compressors/decompressors? I find it strange that
$the author of that article claims that PKZIP 1.02 is by far the
$most efficient and fastest compressor available. From my experiences,
$PKZIP may be fast but it is definitely not the most efficient. It
$seems as though LHarc 1.13C (despite what the article claims and shows)
$produces smaller files the majority of the time. I don't know about
I've found that typically, the files produced by the two programs are
within a couple of percent of each others' sizes. Archives with large
files in them typically come out smaller with PKZIP; archives with small
files in them usually come out smaller with LHarc. These findings do not
seem to depend on whether the files are binary or text. That's what
I've found ... your results may well differ.
$the credibility of such tests but I've done a lot of PKZIPS and LHarcs
$and LHarcs seem more efficient despite its speed that most people
$don't like (it doesn't affect me because I have a 25 mhz 386).
Whether or not it affects you depends more on how much time you have
to spend waiting for the archive program. On a 386, it wouldn't surprise
me if the difference in compression time is about a factor of four or five,
and this _does_ make a difference if you're making large archives.
I have a couple of other comments on the various programs they reviewed,
and have sent a letter to the editor including them. For example, the
author claimed to have never managed to get LHarc to produce a self-extracting
archive; I do this all the time and have never had a problem with it. Also,
the code LHarc uses adds only about 1300 bytes to the size of the archive.
PKZIP, on the other hand, requires you to have their PKSFX.PRG (or whatever
the name is) in the current directory (at least in V1.01 - the documentation
that says it can be anywhere in the path is wrong), and adds a fair bit more
code to the program. On the other hand, LHarc self-extracting files will only
work if you have enough memory, while PKZIP ones will overlay themselves.
Also, the author notes that ZOO is available across many different
systems, but does not mention that LHarc is also available for Unix (I
also have heard of a PKZIP for Unix, though I've yet to see it - if anyone
has a pointer to it, please let me know!). In fact, I find LHarc to be
the best archive/compression utility for Unix, beating ARC and compress
hands down (although once again it takes a bit longer, which isn't usually
much of a concern on a Unix box where you can do something else in the
foreground). Unfortunately, the Unix version of LHarc I have (V0.03 Beta)
is not command-compatible with the DOS one, and has bugs (pointers to a
newer version would be appreciated!). But the files are compatible (the
Unix version, alas, does not implement CRC).
What do I use for various tasks? PKZIP for anything that needs to be
updated frequently, since it's so much faster. PKZIP's fast compression
mode for doing backups of selected files on my hard disk. And for long-
term archiving, whichever of PKZIP and LHarc produces the smaller file.
--
Stephen M. Dunn cs4g6ag@maccs.dcss.mcmaster.ca
<std_disclaimer.h> = "\nI'm only an undergraduate!!!\n";
****************************************************************************
"So sorry, I never meant to break your heart ... but you broke mine."elund@pro-graphics.cts.com (Eric Lund) (03/21/90)
In-Reply-To: message from tt3x@vax5.cit.cornell.edu > most efficient and fastest compressor available. From my experiences, > PKZIP may be fast but it is definitely not the most efficient. It > seems as though LHarc 1.13C (despite what the article claims and shows) > produces smaller files the majority of the time. I don't know about > the credibility of such tests but I've done a lot of PKZIPS and LHarcs > and LHarcs seem more efficient despite its speed that most people > don't like (it doesn't affect me because I have a 25 mhz 386). I have never had any complaints about PKZIP. I would like to mention I am also on Phil Katz Clode Nine right now, having packed a 300,000 byte file to less than 3,000 bytes. Arf. Funny, it's listed as having a 00% compression ratio. I note it may not print three digits, although is 100% accurate? I don't know -- I'm still high and I can't think. Anyway, it may also be interesting to note PKZIP 1.01 does not default to the BEST compression scheme, whereas 1.02 does. Inotherwords, 1.01 is faster, but not as efficient space-wise. Of course, you can IMPOSE the slower mode onto 1.01. That's one of the few "enhancements" of 1.02: Best compressor default. Anyhow, do the tests use PKZIP 1.01 or 1.02? Also, do they mention the compression type? The "extra" compression can really do a good deal of extra cramming I've noticed, and only in some instances does it seem much slower. Eric W. Lund *DISCLAIMER "Disclaimers are for weak people."* Prodigy: xcbr22b UUCP: ...crash!pro-graphics!elund *COWS FOR RENT* ProLine: elund@pro-graphics Internet: elund@pro-graphics.cts.com ** ARPA/DDN: pro-graphics!elund@nosc.mil
cs4g6ag@maccs.dcss.mcmaster.ca (Stephen M. Dunn) (03/23/90)
In article <1897@crash.cts.com> elund@pro-graphics.cts.com (Eric Lund) writes:
[...]
$interesting to note PKZIP 1.01 does not default to the BEST compression
$scheme, whereas 1.02 does. Inotherwords, 1.01 is faster, but not as efficient
$space-wise. Of course, you can IMPOSE the slower mode onto 1.01. That's one
$of the few "enhancements" of 1.02: Best compressor default.
No, V1.01 and V1.02 both default to optimal compression. Only pre-V1.01
PKZIPs default to fast compression.
$Anyhow, do the tests use PKZIP 1.01 or 1.02? Also, do they mention the
$compression type? The "extra" compression can really do a good deal of extra
$cramming I've noticed, and only in some instances does it seem much slower.
BYTE does indeed use both compression methods, and reports the following:
slow: Compressed to 40% in 29 sec, extraction time 10 sec
fast: Compressed to 50% in 10 sec, extraction time 13 sec
The files they used were a combination of text and binary.
--
Stephen M. Dunn cs4g6ag@maccs.dcss.mcmaster.ca
<std_disclaimer.h> = "\nI'm only an undergraduate!!!\n";
****************************************************************************
"So sorry, I never meant to break your heart ... but you broke mine."tt3x@vax5.cit.cornell.edu (03/23/90)
In article <1897@crash.cts.com>, elund@pro-graphics.cts.com (Eric Lund) writes: > In-Reply-To: message from tt3x@vax5.cit.cornell.edu >> most efficient and fastest compressor available. From my experiences, >> PKZIP may be fast but it is definitely not the most efficient. It >> seems as though LHarc 1.13C (despite what the article claims and shows) >> produces smaller files the majority of the time. I don't know about >> the credibility of such tests but I've done a lot of PKZIPS and LHarcs >> and LHarcs seem more efficient despite its speed that most people >> don't like (it doesn't affect me because I have a 25 mhz 386). > > I have never had any complaints about PKZIP. I would like to mention I am > also on Phil Katz Clode Nine right now, having packed a 300,000 byte file to > less than 3,000 bytes. Arf. Funny, it's listed as having a 00% compression > ratio. I note it may not print three digits, although is 100% accurate? I > don't know -- I'm still high and I can't think. Anyway, it may also be > interesting to note PKZIP 1.01 does not default to the BEST compression > scheme, whereas 1.02 does. Inotherwords, 1.01 is faster, but not as efficient > space-wise. Of course, you can IMPOSE the slower mode onto 1.01. That's one > of the few "enhancements" of 1.02: Best compressor default. > > Anyhow, do the tests use PKZIP 1.01 or 1.02? Also, do they mention the > compression type? The "extra" compression can really do a good deal of extra > cramming I've noticed, and only in some instances does it seem much slower. > They do mention the usage of PKZip 1.02 and used it on the benchmarks. I suppose the possibility here is that PKZip compresses big text files better than LHarc whereas LHarc is superior in executables. I find myself compressing executables more than text and thus I use LHarc most of the time... Bobby Li INTERNET: TT3X@VAX5.CIT.CORNELL.EDU INTERNET: BLI@BRUTUS.CIT.CORNELL.EDU INTERNET: LI#BOBBY%MFE.MFENET@ANLVM.CTD.ANL.GOV
elund@pro-graphics.cts.com (Eric Lund) (03/25/90)
In-Reply-To: message from cs4g6ag@maccs.dcss.mcmaster.ca > $interesting to note PKZIP 1.01 does not default to the BEST compression > $scheme, whereas 1.02 does. Inotherwords, 1.01 is faster, but not as efficient > $space-wise. Of course, you can IMPOSE the slower mode onto 1.01. That's one > $of the few "enhancements" of 1.02: Best compressor default. > > No, V1.01 and V1.02 both default to optimal compression. Only pre-V1.01 > PKZIPs default to fast compression. Hmm, if you're sure ... I'll have to check on that. I was reading the "update" file for pkz102 and I'm almost positive that is where I read 1.01 defaulted to faster compression. Perhaps it said 0.92, instead? No matter, the compression times are not very important to me anyway. Decompression times can be a little more so, however. And by your statistics, the extra compression is worthwhile. Tally-ho ... Eric W. Lund *DISCLAIMER "Disclaimers are for weak people."* Prodigy: xcbr22b UUCP: ...crash!pro-graphics!elund *COWS FOR RENT* ProLine: elund@pro-graphics Internet: elund@pro-graphics.cts.com ** ARPA/DDN: pro-graphics!elund@nosc.mil