From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id: <10107291823.AA18378@clio.rice.edu>
Subject: Re: UPX in simtel packages
To: djgpp-workers AT delorie DOT com
Date: Sun, 29 Jul 2001 13:23:13 -0500 (CDT)
In-Reply-To: <200107291153.NAA00588@father.ludd.luth.se> from "Martin Str|mberg" at Jul 29, 2001 01:53:24 PM
X-Mailer: ELM [version 2.5 PL2]
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> I note that the recently released sed is compressed with UPX. Do we
> really want this? I'm thinking of my poor 386 20MiHz. Should we punish
> old boxes like this?

Do some tests.  In early testing on DJP (parent of UPX) the expansion
algorithm was only 3-4 times slower than a memory copy!  Also consider
that older machines tend to have slower hard drives - so the less you
need to read from disk - the faster the load.  When launching from a
floppy disk the UPX compressed images are faster on any tested machine.

I'd love to see any real results from the old 386 for the time to do
something like "gdb -v".  Read note on disk cache below.

After doing some tests on a wide range of machines (386 to Pentium) I
came to the conclusion I'd probably pack any image without worrying about
it (and definitely DJP everything I didn't use several times a day).

I haven't benchmarked UPX, so things may have changed.  But on disk space
starved machines, it's a huge blessing with very little cost.  Also 
consider that the compressed files fit in your disk cache more easily,
making it more effective.  You can craft some tests (say a 1Mb disk
cache launching gdb -v in a loop with and without compression) and make
UPX look like a huge upgrade.  A 537K compressed GDB in the cache will
scream compared to a 1418K raw GDB loaded from 1990 vintage hard drive.