From owner-freebsd-hackers Tue Mar 14 12:55:50 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id MAA00411 for hackers-outgoing; Tue, 14 Mar 1995 12:55:50 -0800 Received: from devnull.mpd.tandem.com (devnull.mpd.tandem.com [131.124.4.29]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id MAA00403 for ; Tue, 14 Mar 1995 12:55:39 -0800 Received: from olympus by devnull.mpd.tandem.com (8.6.8/8.6.6) id NAA28866; Tue, 14 Mar 1995 13:00:48 -0600 Received: by olympus (4.1/TSS2.1) id AA02884; Tue, 14 Mar 95 12:59:17 CST From: faulkner@mpd.tandem.com (Boyd Faulkner) Message-Id: <9503141859.AA02884@olympus> Subject: Re: install compressed binary patch To: davidg@Root.COM Date: Tue, 14 Mar 1995 12:59:16 -0600 (CST) Cc: kargl@troutmask.apl.washington.edu, phk@ref.tfs.com, freebsd-hackers@freefall.cdrom.com In-Reply-To: <199503140103.RAA00471@corbin.Root.COM> from "David Greenman" at Mar 13, 95 05:03:32 pm X-Mailer: ELM [version 2.4 PL17] Content-Type: text Content-Length: 1784 Sender: hackers-owner@FreeBSD.org Precedence: bulk > > >> Wouldn't you gain more diskspace if you told cc(1) about ".gz" files for > >> instance ? source compress better than binary I'd expect... > > > >Actually, make world was a (poor?) example. But, consider the installation > >on a production machine of some of the ports. The binary for Octave was over > >4 MB before compression. With `gzip -9', the binary is around 750 KB. I get > >similar compression for other large binaries. > > > >The `-z' would be useful perhaps for XFree86 where the site.def(?) file allows > >one to specify the install program and install flags (if i recall correctly). > >Then, you can automatically have X built with compressed binaries. > > Keep in mind the following when using gziped binaries: > > 1) The file is paged from swap, not from the executable. This means > you'll need a lot more swap space. > 2) There is no sharing with gziped binaries. This means that you'll > need a lot more memory (and swap space). > 3) Decompression requires a lot of CPU. > > Those three reasons make it impractical to gzip binaries that will be used > often or ones where multiple copies are used concurrently (like a shell for > instance). > > -DG > I was getting ready to ask about 1). Couldn't 2) be fixed? Taking an SVR4 internals class and now I can ask all kinds of stupid questions! Boyd I am not implying that 2) is worth fixing but with it's own file system and operations, it seems you could redirect the vnode to point into swap if the refcnt is greater than 0. Please tell me if I'm wrong. -- _______________________________________________________________________ Boyd Faulkner faulkner@isd.tandem.com _______________________________________________________________________