Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!tut.cis.ohio-state.edu!ucbvax!ulysses!ulysses.att.com!cjc
From: cjc@ulysses.att.com (Chris Calabrese)
Newsgroups: comp.unix.internals
Subject: Re: Compressed executables
Message-ID: <14229@ulysses.att.com>
Date: 28 Jan 91 13:54:38 GMT
References: <1991Jan15.204849@IASTATE.EDU> <118868@uunet.UU.NET> <3977@skye.ed.ac.uk> <1991Jan23.123808.22159@grep.co.uk> <4001@skye.ed.ac.uk>
Sender: netnews@ulysses.att.com
Organization: AT&T Bell Laboratories, Murray Hill
Lines: 25

In article <4001@skye.ed.ac.uk> richard@aiai.UUCP (Richard Tobin) writes:
>In article <1991Jan23.123808.22159@grep.co.uk> vic@grep.co.uk (Victor Gavin) writes:
>>And perhaps they could also explain why it doesn't slow the system down, coz if
>>the processor has enough time to decompress something coming off the disk, it
>>has enough time to go and run another program.
>
>It seems pretty clear that it's trading cpu time for disk space and
>disk accesses.  On a reasonably fast workstation with small slow
>disks, it seems likely to be a winning tradeoff.

Yes.  One very big win for compressed executables is when the
workstation has 'disks' mounted over a very slow link (say 9600 baud).

In fact, one might even want a compressed file system type for
mounting remote disks from a home machine.  You can usually get
something like 3:1 on executables and 10:1 on English text, so a
workstation with a 9.6kb link with most of the executables local
and much of the documents, etc. remote would behave like it had a 96kb
link.  Remember, this is a direct pipe (not shared like ethernet), so
you could actually get reasonable performance.

Name:			Christopher J. Calabrese
Brain loaned to:	AT&T Bell Laboratories, Murray Hill, NJ
att!ulysses!cjc		cjc@ulysses.att.com
Obligatory Quote:	``pher - gr. vb. to schlep.  phospher - to schlep light.philosopher - to schlep thoughts.''