🚀 go-pugleaf

In article <76000213@uiucdcsp> gillies@uiucdcsp.cs.uiuc.edu writes:
>But when I benchmarked compress on some digital pictures, I found that
>stuffit's LZW algorithm is much more efficient than compress's
>algorithm.  I'm not sure compress is all that great a program.  If you

Interesting, since compress *is* using the LZW algorithm.  I believe the
only differences in compress are hacks to make the hash table lookups
faster, which shouldn't affect its output.  The interesting question is,
just what is stuffit doing that compress isn't?  
  Another interesting question--just what level of LZW code is being used
by the two programs (stuffit and compress).  Since the Mac doesn't have
evil segment registers from hell, I'd expect stuffit and the Mac compress
port to use 16-bit LZW, since the higher number of bits the better and
on the Mac you wouldn't be forced to limit the number because of CPU
braindamage, but I don't know.  

>So I'm not voting for making compress a standard.  I believe stuffit
>is better.
   Could be.  I haven't noticed much difference between compress and the
various PC-based LZW-compression programs (ARC,PKXARC,ZOO) in terms of 
output size.  I don't have a Mac, so I can't comment directly on the
Mac implementations.  Differences between # of bits used in LZW compression
do make some difference on really large files (e.g. Gnu CC source went from 
1.4M to 1.7M in going from 16-bit LZW to 13-bit.)  Could you provide us with
some actual test figures?
--
Richard Todd		Dubious Domain: rmtodd@uokmax.ecn.uoknor.edu
USSnail:820 Annie Court,Norman OK 73069 	Fido:1:147/1
UUCP: {many AT&T sites}!occrsh!uokmax!rmtodd
"Indulgent is a word that anyone who doesn't like progressive rock can call
you" - Eddie Jobson