Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!att!pacbell.com!ucsd!mvb.saic.com!ncr-sd!crash!nusdecs!nusjecs!ozonebbs!steven From: steven@ozonebbs.UUCP (Steven Rubin) Newsgroups: comp.binaries.ibm.pc.d Subject: Re: maximal compression utility sought Message-ID: Date: 29 Dec 90 01:54:41 GMT References: <1990Dec27.122635.1031@kcbbs> Organization: The ()zone BBS, +1 408 223 1738 Lines: 31 Peter_Gutmann@kcbbs.gen.nz (Peter Gutmann) writes: > I'm currently working on an archiver which which is supposed to outperform > but ZIP and LHARC (and it does for all test data I can get my hands > on - about 10MB of stuff). If you aren't worried about SLOW compression > you'll LOVE this program - it crawls :-). Actually its not *that* bad > (1/2 the speed of LHARC, 1/3 the speed of ZIP) and I hope to speed it > up somewhat by rewriting the compressor in assembly language. As to > its compression, I won't make any claims here but it's not that much > better than ZIP and LHARC. In fact as far as compressors go ZIP and > LHARC are pretty well as good as you can get - there are better compression > schemes but they tend to need a Cray to run on. In short you can (as > fasr as I know) get slightly better compression than ZIP/LHARC at the > cost of slow compression/decompression. > > It is possible to do slightly better than ZIP and LHARC but if you want > significantly better performance you'll probably have to implement the code > yourself, and run it on a LARGE system...... > > Peter. As a side note, I received the new ARC+ from Sea a while ago. Suprisingly, it does create smaller files then PKZIP, But ARC+ isnt Shareware, and with SEA's good atitude, I wouldn't Buy anything from them! --- Steven Rubin @ @ {netcom, crash!nusdecs}!nusjecs!ozonebbs!steven oo Disclaimer: I don't even speak for myself! \__________/