Date: Thu, 5 Oct 1995 13:26:19 +0800 (WST) From: Peter Wemm <peter@jhome.DIALix.COM> To: Satoshi Asami <asami@cs.berkeley.edu> Cc: joerg_wunsch@uriah.heep.sax.de, CVS-commiters@freefall.freebsd.org, cvs-ports@freefall.freebsd.org Subject: Re: cvs commit: ports/devel/cflow/patches patch-aa Message-ID: <Pine.BSF.3.91.951005132159.509F-100000@jhome.DIALix.COM> In-Reply-To: <199510050455.VAA07443@silvia.HIP.Berkeley.EDU>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 4 Oct 1995, Satoshi Asami wrote: > * > "gzip --best" -> "gzip -9nf" for manpage compression. Otherwise it > * > will ask if you want to overwrite it if the compressed manpage already > * > exists. > * > * I thought we won't use "gzip -9" any more? > > Joerg, there are so many ports out there with gzip -9 in there, and > now is not the time to go fix all of them. :> > > Besides, I don't think any conclusion came out of the discussion a > while ago. However, if you ask me, I'd rather keep the -9 in there > (or whatever the "best" compression is, in terms of compression ratio, > regardless of speed). I think most of our users out there use binary > packages, so the extra time we pay, will save space for thousands of > them. :) My sentiments exactly. For "once compressed, many, many times decompressed" type arrangements, gzip -9 is probably fine. For things like the wuftpd's ftpconversions file, it most definately should be gzip -1 - who out there is running a busy ftp server and can afford to have their gzip's using 6 times more cpu for a couple of extra percent compression? :-) Also, In the man page case, the overhead of actually invoking the "gzip" executable from the makefile is probably greater than the time to actually compress it. :-) -1 or -9 for the average small manpage is probably not going to make much of a measurable difference time-wise. Cheers, -Peter > Satoshi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.91.951005132159.509F-100000>