home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / compress / 4146 < prev    next >
Encoding:
Internet Message Format  |  1992-12-14  |  1.7 KB
  1. Path: sparky!uunet!mcsun!julienas!chorus!octave.chorus.fr!jloup
  2. From: jloup@chorus.fr (Jean-loup Gailly)
  3. Newsgroups: comp.compression
  4. Subject: Re: How much memory does MW compression really need?
  5. Message-ID: <1420@chorus.chorus.fr>
  6. Date: 14 Dec 92 16:04:45 GMT
  7. References: <1992Dec13.195334.5652@plex-1.ann-arbor.mi.us>
  8. Sender: jloup@chorus.chorus.fr
  9. Reply-To: jloup@chorus.fr (Jean-loup Gailly)
  10. Lines: 31
  11.  
  12. David West <dhw@plex-1.ann-arbor.mi.us> writes:
  13.  
  14. > I've compiled Dan Bernstein's implementation of Miller-Wegman compression  
  15. > ("sqz" from comp.sources.somethingorother).
  16.  
  17. comp.sources.unix, Volume 21, Issue 1, 6 Feb 90.
  18.  
  19. > The included comments say that it's "even more of a memory hog than
  20. > Compress".  Well, compress runs in 400K, but sqz (with no other tasks
  21. > running) thrashes and then dies on my Unix box (6MB real memory, 5MB
  22. > swap space) trying to compress a 100K file.  Anyone know how much
  23. > memory is comfortable for it?  Or is something else the problem?
  24.  
  25. On the file book2 from the Calgary corpus, squeeze requires 5M of
  26. virtual memory and uses about 4M of physical memory (obtained with
  27. "ps -v" on a SparcStation SLC with 8M of physical memory). By comparison,
  28. zip 1.9 uses about 0.5M of physical memory, runs 4 to 7 times as fast
  29. (elapsed time on an idle machine) and compresses better than squeeze:
  30.  
  31.          original  compress   squeeze     zip -5   zip -1
  32.  
  33. size     610,856   250,759    230,862    206,771   217,341
  34. user                4.840u    18.350u    13.030u    8.040u
  35. system              0.600s     4.140s     0.500s    0.390s
  36. elapsed           0:05.93e   1:08.69e   0:15.08e  0:09.39e
  37.  
  38. Because of the higher memory usage, squeeze pages much more. This
  39. explains the higher ratio elapsed time/cpu time.
  40.  
  41. Jean-loup Gailly
  42. jloup@chorus.fr
  43.