From owner-freebsd-bugs Mon Dec 16 00:00:37 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id AAA12083 for bugs-outgoing; Mon, 16 Dec 1996 00:00:37 -0800 (PST) Received: from hauki.clinet.fi (root@hauki.clinet.fi [194.100.0.1]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id AAA12078 for ; Mon, 16 Dec 1996 00:00:29 -0800 (PST) Received: from cantina.clinet.fi (root@cantina.clinet.fi [194.100.0.15]) by hauki.clinet.fi (8.8.2/8.6.4) with ESMTP id KAA17851; Mon, 16 Dec 1996 10:00:10 +0200 (EET) Received: (hsu@localhost) by cantina.clinet.fi (8.8.2/8.6.4) id KAA03485; Mon, 16 Dec 1996 10:00:09 +0200 (EET) Date: Mon, 16 Dec 1996 10:00:09 +0200 (EET) Message-Id: <199612160800.KAA03485@cantina.clinet.fi> From: Heikki Suonsivu To: David Muir Sharnoff Cc: freebsd-bugs@freebsd.org In-reply-to: David Muir Sharnoff's message of 16 Dec 1996 03:52:30 +0200 Subject: Re: Re: bin/146 Organization: Clinet Ltd, Espoo, Finland References: <199612160141.RAA10917@idiom.com> Sender: owner-bugs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article <199612160141.RAA10917@idiom.com> David Muir Sharnoff writes: * Synopsis: version of compress is kinda old and slow Until gzip is faster than compress, there is still a use for compress. ncompress-4.2.4 is faster than gzip. Not by much anymore, but still a bit faster. gzip is by default doing best compression ratio, not best speed. Compress performance and memory use can be tuned also, using -b option, but compression performance drops dramatically while gzip options do not make that much a difference (gzip -1 still compresses better than compress at its best, and result is half of what compress -b12 makes!): time ratio decompress ncompress 4.2.4 -b12 6.80+1.06 60.4% 3.68+1.27 gzip -1 10.49+0.68 31.4% 3.46+0.21 ncompress 4.2.4 13.01+1.48 46.9% 4.12+1.11 /usr/bin/compress 18.45+0.89 43.6% 6.68+0.31 gzip 27.98+0.65 26.8% 3.25+0.18 Most results are from /usr/bin/time, it seems that the test was a bit too short as time vary. Curiously freebsd compress produced a smaller file than never compress ? As long as someone is going to be done with the resulting files, like transferring them through something slower than ethernet the extra compression time will be saved in transfer time (and money, often!) compress is to my knowledge patent-hampered, so it also would not serve all the audience listening. For people who need the best compression speed I would rather suggest gzip -1. I cannot really see why anyone would want to use slightly faster compress when compression result is that much worse ? hsu@zetor.clinet.fi Mon 50: date ; ./compress < /kernel | wc -c ; date Mon Dec 16 08:46:01 EET 1996 4592777 real 0:16.59; user 13.014; system 1.475; cpu 87.2%; swaps 0; disk reads 116; disk writes 1; average size 1187; max size 542 Mon Dec 16 08:46:17 EET 1996 hsu@zetor.clinet.fi Mon 51: date ; /usr/bin/compress < /kernel | wc -c ; date Mon Dec 16 08:46:27 EET 1996 4270573 real 0:21.20; user 18.454; system 0.894; cpu 91.2%; swaps 0; disk reads 0; disk writes 1; average size 746; max size 482 Mon Dec 16 08:46:48 EET 1996 hsu@zetor.clinet.fi Mon 52: date ; gzip -1 < /kernel | wc -c ; dateMon Dec 16 08:47:00 EET 1996 3068781 real 0:12.60; user 10.485; system 0.683; cpu 88.5%; swaps 0; disk reads 0; disk writes 1; average size 722; max size 390 Mon Dec 16 08:47:13 EET 1996 hsu@zetor.clinet.fi Mon 53: date ; gzip < /kernel | wc -c ; date Mon Dec 16 08:47:17 EET 1996 2620417 real 0:31.59; user 27.979; system 0.645; cpu 90.5%; swaps 0; disk reads 0; disk writes 0; average size 727; max size 262 Mon Dec 16 08:47:49 EET 1996 hsu@zetor.clinet.fi Mon 54: -Dave -- Heikki Suonsivu, T{ysikuu 10 C 83/02210 Espoo/FINLAND, hsu@clinet.fi mobile +358-40-5519679 work +358-9-43542270 fax -4555276