Path: utzoo!attcan!lsuc!maccs!cs4g6ag From: cs4g6ag@maccs.dcss.mcmaster.ca (Stephen M. Dunn) Newsgroups: comp.sys.ibm.pc Subject: Re: BYTE's compressor/decompressor tests? PKZIP vs. LHarc Message-ID: <2606BF61.4307@maccs.dcss.mcmaster.ca> Date: 20 Mar 90 23:40:16 GMT References: <3657.26037c1b@vax5.cit.cornell.edu> Reply-To: cs4g6ag@maccs.dcss.mcmaster.ca (Stephen M. Dunn) Distribution: comp Organization: McMaster University, Hamilton, Ontario Lines: 57 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 = "\nI'm only an undergraduate!!!\n"; **************************************************************************** "So sorry, I never meant to break your heart ... but you broke mine."