"Raab, Andreas" <Andreas.Raab at disney.com> is widely believed to have written:

> Dan,
> 
> > Here's another slant on this.  Suppose we always gzipped the 
> > images.  This typically saves 50%.  So we would have...
> 
> Cool idea!
Dan Lanovaz did a study on this at ParcPlace some years back (and so the
relative performances of the components may very well have changed since
then) and his conclusions were that some machines (typically back then
PCs) were much better off using zipped images andsome were much worse
off. IIRC, the typical PC of the day had relatively slow disks and poor
network performance, so the decompressing saved a bunch of transfer
time. The unix workstations we had available typically had fast disk and
network access, so did better without compresion. I imagine these days
that the disk performance is much improved on most machines and of
course the disk size has massively increased.

Of course, there is little chance that typical fast machines would be
discommoded by using zipped images, and PDAs would benefit quite a bit,
and I guess it might even be helpful to use the compression
checksum/whatever data to check the integrity of the image upon loading.
It might be a good idea to have some sensitivity to local filing systms
though - there are instances that do compression automagically and it
would potentially be quite time wasting to pass them a previously
compressed data stream.

How about compressing the sources & changes files, like the Digitalk
systems used to? On my Acorn, the sources files seem to compress ~2.5:1
which is a useful space saving.

tim

-- 
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
There can never be a computer language in which you cannot write a bad program.