This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

gzip performance test

The release criteria specified that we'd do a number of performance tests,
and one of the simpler ones is gzip.

While we no longer consider the performance criteria to be mandatory for
release (barring something truly awful), we should at least run the tests
to see where we stand.

Summary: gzip is one or two percent faster with 3.0-pre than with 2.95.2
on both sparc and i686.

The test: build gzip 1.2.4a, both with the 3.0 prerelease and 2.95.2.
Compare their performance.

For test data I ungzipped SN452.tar.gz (Red Hat's Source Navigator),
giving a 59146240 byte tar file.  I then timed

gzip -c -9 /tmp/SN452.tar > /dev/null

(/tmp is used to make sure we're on a local disk)

To avoid noise from other system activity I ran the test 5 times and
took the median.  I'm taking the user-time figure output by "time".

First platform: sparc-sun-solaris2.7
The server is an 8-processor server with 8GB of RAM; each CPU is a 400 MHz

For 2.95.2, we get 58.59 seconds.

For the 3.0 prerelease as of yesterday, we get 57.71 seconds.  The
difference isn't noise, the 1-2% difference is consistent over multiple
runs, so the new compiler gives very, very slightly faster code.

Next, I tried a Red Hat 6.2 box (i686-pc-linux-gnu).  This is a 330 MHz
Pentium II with 192k memory.  I did the tests from the console because
it's got the new Gnome on it and Nautilus is such a pig.  Same conditions
as above.

2.95.2 : 103.33 sec
3.0-pre: 102.09 sec

Again, despite the small difference, it seems to be significant; all
five 3.0 runs were faster than all five 2.95.2 runs.  But it's only
1%, I was hoping that the x86 backend improvements would make more
of a difference.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]