home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / compress / 3020 < prev    next >
Encoding:
Internet Message Format  |  1992-08-14  |  1.6 KB
  1. Path: sparky!uunet!zaphod.mps.ohio-state.edu!sdd.hp.com!uakari.primate.wisc.edu!ames!agate!bho
  2. From: bho@ocf.berkeley.edu (Bing Ho)
  3. Newsgroups: comp.compression
  4. Subject: Re: DELETE PROTECTION AND FILE FIX UNDER ON-THE-FLY COMPRESSION
  5. Message-ID: <16he2oINNks4@agate.berkeley.edu>
  6. Date: 14 Aug 92 23:02:48 GMT
  7. References: <1992Aug11.172604.29703@ncsu.edu> <169b62INNemt@agate.berkeley.edu> <2984@accucx.cc.ruu.nl>
  8. Organization: U.C. Berkeley Open Computing Facility
  9. Lines: 28
  10. NNTP-Posting-Host: tornado.berkeley.edu
  11.  
  12. In article <2984@accucx.cc.ruu.nl> nevries@accucx.cc.ruu.nl
  13. (Nico E de Vries) writes:
  14.  
  15. >For larger .EXE .SYS .COM files diet etc do better. Anyone using Clipper
  16. >will be very glad about that :-).
  17.  
  18. That's very interesting to know.  Which of the compressors, pklite,
  19. diet, or lzexe does best for compression?
  20.  
  21. >This is not the main reason. The main reason archivers etc do better than
  22. >Stacker is the speed vs ratio limit. Stacker is faster than most
  23. >archivers but therefore has a worse compression ratio. Also notice there
  24. >are compressors even slower than ARJ with more compression. The limit
  25. >seems to be the Ashford compressor taking hours for an file at about
  26. >30% more compression than ARJ (see comp.compression FAQ for more info). 
  27.  
  28. That's true for perfectly programmed algorithms.  However, until that
  29. occurs, there are many ways to optimize existing schemes for speed.
  30. There is always an inverse proportion to speed and compression, but
  31. I find that optimizing still has a lot to do with speed.  The question I
  32. would like answered is if Stacker's scheme is inherently worse than the
  33. prevalent zip, arj, lzh schemes.
  34.  
  35. >Nico E. de Vries
  36.  
  37.  
  38. Bing Ho
  39. bho@ocf.berkeley.edu
  40.