home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / os / linux / 7094 < prev    next >
Encoding:
Text File  |  1992-07-30  |  1.9 KB  |  38 lines
  1. Newsgroups: comp.os.linux
  2. Path: sparky!uunet!usc!cs.utexas.edu!qt.cs.utexas.edu!yale.edu!yale!mintaka.lcs.mit.edu!bloom-picayune.mit.edu!athena.mit.edu!pshuang
  3. From: pshuang@athena.mit.edu (Ping-Shun Huang)
  4. Subject: Re: Why ZIP/UNZIP slower than DOS version?
  5. In-Reply-To: Ching-Hsiang Chen's message of Fri, 31 Jul 1992 05:09:21 GMT
  6. Message-ID: <PSHUANG.92Jul31024836@beeblebrox.mit.edu>
  7. Sender: news@athena.mit.edu (News system)
  8. Nntp-Posting-Host: beeblebrox.mit.edu
  9. Organization: Massachusetts Institute of Technology
  10. References: <1992Jul31.050921.19572@athena.mit.edu>
  11. Date: Fri, 31 Jul 1992 06:48:46 GMT
  12. Lines: 24
  13.  
  14. In article <1992Jul31.050921.19572@athena.mit.edu> Ching-Hsiang Chen <chchen@stat.fsu.edu> writes:
  15.  
  16.  > I am using the zip/unzip binaries from tsx-11(or banjo?). The zipping
  17.  > /unzipping speed is far slower than the pkzip/pkunzip DOS version,
  18.  > especially for large files (>= 100k). Anyone has the same problem?
  19.  
  20. I assume that the binaries you are using are results of the recent port
  21. to Linux of the code from the Info-ZIP project. Two reasons they seem
  22. slower than PKZIP/PKUNZIP 1.1 for DOS are: (a) PKZIP/PKUNZIP are coded
  23. in assembler (probably with reasonable care toward optimization by
  24. PKWare, Inc.) whereas Info-ZIP source code is portable C and not
  25. hand-optimized for any particular platform; (b) Info-ZIP's recent
  26. releases by default use a compression algorithm whimsically named
  27. deflation (as opposed to PKZIP 1.1, which uses implosion)... PKZIP 2.0
  28. will be using deflation as well, and my experience (playing around with
  29. PKZIP 1.93 alpha) is that deflation tends to be a bit slower than
  30. implosion anyway (but gives ratios in the ballpark of ARJ). Whether this
  31. (performance hit) is true in the general case or will be true for PKZIP
  32. 2.0 release, I don't know, but that the two archivers are using
  33. different algorithms is a good reason for their performance to differ.
  34.  
  35. --
  36. Ping Huang (INTERNET: pshuang@athena.mit.edu), probably speaking for himself
  37.  
  38.