Some timings

    file: pgp26is.tar (2088960 bytes)
    > gzip -9N pgp26is.tar
    > gzip -dN pgp26is.tar.gz

    (why the -N? just because I use it always (in $GZIP))
    For Mac users:
        gzip -9N := gzip, compress, level 9, save original name
        gzip -dN := gzip, decompress, restore original name

The machines:

MacOS 7.5.1, MacSE 1/20 (68000 8 MHz), MacGzip 1.0b1 mw/68k
MacOS 7.5.1, Macintosh IIfx, (68030 40MHz)
MacOS 7.5.1, Power Macintosh. (Upgraded Quadra 950) PowerPC 601. (66 MHz)
MacOS 7.5.3r2 (9500/132) PowerPC 604 132 MHz, MacGzip 1.0 mw/PPC
HP-UX B.09.00 B 9000/43S (68040 33 MHz)
HP-UX A.09.05 A 9000/735 (HPPA 99 MHz)
IRIX 5.3 IP19 mips (SGI Onyx, R4400 150 MHz)
IRIX 5.3 IP19 mips (SGI Challenge R4400 200 MHz)
IRIX 5.3 IP22 mips (SGI Indy  R4600PC 100 MHz)
SunOS 4.1.3_U1 2 sun4m (SPARCstation 20 60 MHz)
SunOS 4.1.3_U1 2 sun4m (IPC, Sun 4/40 25 MHz)
SunOS 5.4 sparc SPARCstation-5 (MicroSPARC II 85 MHz)
SunOS 5.5 sparc SPARCstation-20 150 MHz Ross,RT626
SunOS 5.5 sparc SPARCstation-20 150 MHz Ross,RT626, MAE 2.02LM, System 7.1
VAX/VMS V5.5 (VAXstation 4000 Model 60)
DOS 6.2, 80386 33MHz
DOS 6.2, 80486 66MHz
Windows NT 3.5, Pentium 90 MHz
WinNT 4.0, Pentium 133 MHz (gzip-winnt 1.2.3)
SunOS 5.5 Generic i86pc i386 i86pc (Pentium 133 MHz)

(for further details, see  this list)

Note: times for Unix and VMS are 'user' time (the part
of the real time which OS gave to gzip); the rest is
'real' time. (for gzip 1.2.4 with Think C command line
interface and for DOS gzip would be the same as user time,
for the rest,  we don't know how much of the time our
application was running and how much was used for
background tasks)


MacGzip:

MacGzip is not the same program as 'gzip 1.2.4', since
it draws windows, progress bars, does some translations
while reading/writing to disk, etc etc, so it always will
be slower. This is the price of a  GUI...

For instance, you can notice in the Mac IIfx, the times
for MacGzip are 2:36, while for MachTen (unix), 1:31.7.
(So, I guess for the 9500 with MkLinux, times will be below
10 seconds.)

About real and user time, in a real multitasking system
(Unix) the performance is better, since if no other
process is running, the system won't interrupt ours
(well, not too often); but in MacGzip, we give the
control to OS every few instructions; regardless if
it needs it or not.

Before you ask, no, I don't know why decompression is
so slow; maybe is because of the checks I have to make
when writting in order to see if is macbinary, ascii, etc...


Some of the machines have more than one CPU; but gzip
is not a parallel program, so it does not makes any
difference.