Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!rutgers!deimos.cis.ksu.edu!eecea!khc
From: khc@eecea.eece.ksu.edu (Ken Carpenter)
Newsgroups: comp.binaries.ibm.pc.d
Subject: Re: lharc algorithm (was Re: Final Vote Tally/Summary)
Summary: Timing lzhuf shows it much slower on large, redundant files
Keywords: lharc, lzhuf, zoo, compress, timings
Message-ID: <617@eecea.eece.ksu.edu>
Date: 11 Apr 89 17:25:22 GMT
References: <19456@iuvax.cs.indiana.edu>
Reply-To: khc@eecea.UUCP (Ken Carpenter)
Organization: Kansas State University, Manhattan
Lines: 44

I have compiled the file lzhuf.c on a 3B1 and a 16MHz MSDOS PC (using TurboC).
On the 3B1 the resulting executable could compress, but dumped core when
attempting to expand the compressed file.  I decided to try compressing the
"core" file just dumped.  (It was about 90Kbytes long.)  At first I thought
I had hung the system, but it turned out just to be an extremely long
compress time.  I compressed the same "core" file using 16bit "compress"
and it went much more quickly.  Here are the timings on the 3B1:
  time lzhuf e core core.lzh
  input: 90112 bytes
  output: 10045 bytes
  output/input: 0.111
   real  4m10.36s
   user  4m6.85s
   sys   0m0.95s

  time compress -v core
  core: Compression: 87.95% - replaced with core.Z
   real  0m9.55s
   user  0m5.23s
   sys   0m0.96s
(the file core.Z was 10858 bytes long).

I copied the "core" file to the MSDOS PC.  Besides the LZHUF program, 
I have the 16bit compress program (also compiled with TurboC) on it.
The LZHUF program on the PC works for both e and d.  The file sizes
when compressed are almost the same as on the 3b1 (but not quite -
suggesting that the lzhuf e output on the 3b1 is bad).  The timings
on the MSDOS 386 PC were:
 For LZHUF e core c1 - 55seconds
 For COMPRESS core   - 22seconds
(compress on the PC used the "large" model, and is noticably slower
then a 12 bit compress using "small" model.)
While the 4minutes on the 3B1 to lzhuf e core, may be analomous due to
a bug in implementation there, it was obvious while watching the
screen indications of number of bytes read that LZHUF slowed down
a lot as the number of bytes got higher and higher.  Thus it may not
be a good choice for compressing large, highly redundant files.
For comparison, times for compressing "core" on the PC using the other
programs were:
  pkarc a core core -- 24sec, core.arc was 12040bytes long
  zoo -add core core - 17sec, core.zoo was 12435bytes long
--------------------------------
Ken Carpenter -   internet:  khc@eecea.eece.ksu.edu
                  UUCP: rutgers!ksuvax1!eecea!khc