Compressed executables

[Chris Calabrese]

In article <4001 at skye.ed.ac.uk> richard at aiai.UUCP (Richard Tobin) writes:
>In article <1991Jan23.123808.22159 at grep.co.uk> vic at 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 at ulysses.att.com
Obligatory Quote:	``pher - gr. vb. to schlep.  phospher - to schlep light.philosopher - to schlep thoughts.''