Re: Is /bin/zip large file aware?

Joerg Schilling <js@xxxxxxxxxxxxxxx> wrote:
> First: you should compare gzip -9 with bzip2 -9 and 30% may have been too
> much, but 20% is a real value.

bzip2 does compress by default with -9, so any higher compression values
with gzip instead of the default (-6) will favour gzip.

My own results (all times user times)

(1) gcc-4.0.2.tar
original size: 228096000
bzip2 -9: 31793239 (86%) 86.84s
gzip -9: 41883001 (81%) 26.45s
gzip -3: 48905494 (78%) 8.12s
bunzip2: 15.93s
gunzip: 1.88s (-9 file)
gunzip: 2.06s (-3 file)

So in this case bzip2 compresses ~25% better than gzip


Then gcc compiled and packaged:

(2) gcc.pkg
original size: 132435968
bzip2 -9: 33404622 (75%) 34.51s
gzip -9: 37572766 (72%) 36.48s
gzip -3: 41121051 (69%) 6.34s
bunzip2: 10.65s
gunzip: 1.43s (-9 file)
gunzip: 1.55s (-3 file)

In this case bzip2 is only ~10% better. But gzip is slower during
compression.


Now to the streaming throughput:

compression decompression
(1) bzip2 -9: 2.5 MB/s 13.6 MB/s
gzip -9: 8.2 MB/s 115.7 MB/s
gzip -3: 26.8 MB/s 105.6 MB/s

(2) bzip2 -9: 3.6 MB/s 11.9 MB/s
gzip -9: 3.4 MB/s 88.3 MB/s
gzip -3: 19.9 MB/s 81.5 MB/s


My experience so far: If the source can be compressed much (80-90% and more)
- these are normally text files (like the gcc source, log files, etc.) then
bzip2 has a 20-30% better compression ratio than gzip. With lower compression
ratios the differences get smaller.

It all depends on your preferences: Do you want to spend one more minute
during compression/decompression for 10 MB space saved, then use bzip2?

It also depends how you calculate the difference: Compared to the original
size you only gain additional 4-5% with bzip2 over gzip...


[Above results measured with a 2.2GHz Athlon64]

--
Daniel
.