Steve G wrote:
Now try to get the -9 changed in rpm.
brp-compress:
@@ -8,8 +8,8 @@ cd $RPM_BUILD_ROOT
# Compress man pages
-COMPRESS="gzip -9 -n"
-COMPRESS_EXT=.gz
+COMPRESS="bzip2 -9 -n"
+COMPRESS_EXT=.bz2
The patch is the easy part ;-)
And it also makes little sense to bzip tarballs that end up in gzipped payloads imho.
I was referring to *.src.rpm's, rather than man pages. Apologies for the confusion.
It does when you realize that loading a man page is milliseconds slower to bring
up using bzip2. And downloading updates via a modem can be 10's of minutes faster
when they are compressed with bzip2. Compare the size of virtually any tarball:
kde, kernel, open office, tetex, .... You can fit more packages on an iso CD,
too.
Yep, user response time for man needs to be considered too. So does build startup times
when uncompressing big honking tarballs from *.src.rpm's.
Looking through the bzip2 source code, it looks like its been optimized pretty
well. But, there is a little room for improvement - even in C and no assembler
has been added.
The threading is prolly a bigger win than any optimize, as bulk data decompression is invariably i/o,
not cpu, bound. Trickier when a serial stream is used to concatenate blocks, or blocks are chained, too.
73 de Jeff
