> If g(un)zip developers become activated again, we could
> yet see a new version of (at least) gunzip which can handle
> BZ2, and thus all complaining is over. After all, gunzip
> can already open BSD compress, and (SysV?) pack files!
>
> Once that happens, and has been deployed for at least 6 months,
> we can scrap the GZ format in favour of BZ2.
[..]
> # time bunzip2 -c linux-2.2.0-pre4.tar.bz2 > linux-2.2.0-pre4.tar
> real 0m33.806s
> user 0m31.706s
> sys 0m1.692s
> # time gunzip < linux-2.2.0-pre4.tar.gz > tmp.tmp
> real 0m8.801s
> user 0m5.278s
> sys 0m1.456s
>
> The beast clearly needs lots of tuning, as bunzip2 is slower
> than gunzip by factor 3.8 (but your CPU is free, isn't it ?)
I don't think that either of these factors is necessarily the most
important one for deciding how to compress development kernels. There
is another factor which was, until very recently, quite important to
me and which put a thumbs down (for me) against bzip2.
To get a couple of numbers, I did the following:
# gunzip < linux-2.1.131.tar.gz > linux-2.1.131.tar
# bzip2 linux-2.1.131.tar
(1) # gunzip < linux-2.1.131.tar.gz > /dev/null
(2) # bunzip2 < linux-2.1.131.tar.bz2 > /dev/null
With gunzip, (1) above, the SIZE and RSS went up to 380k. With
bunzip2, (2) above, the SIZE and RSS went up to 4728k. It appears
that bzip2 gets its performance at the expense of a huge increase in
memory use during *uncompressing* (what it uses during compressing
doesn't matter for this discussion).
So what?, you might say. The point is that this is *really* bad news
if you are using a machine with limited memory resources. Until
recently, my only machine had 8 MByte of RAM. I once made the mistake
of being lured by the smaller size of a .bz2 file (I don't remember
what it was, but it was something quite large - probably the kernel
source) and then found that uncompressing it took something like an
hour instead of less than a minute (which a .gz file would have taken)
and the machine thrashed the swap disk for the whole time. I was not
amused.
My current machine has 64 MByte, so this particular issue isn't all
that important to me anymore but perhaps there are still a few people
out there with (relatively) limited memory machines who would like to
follow kernel developments...
-- ----------------------------------------------------------------------------- Bill Metzenthen | See http://www.suburbia.net/~billm/ for information billm@melbpc.org.au | on an 80x87 FPU emulator, using floating point billm@suburbia.net | (particularly on Linux), and code for manipulating Melbourne, Australia | the floating point environment on 80x86 Linux. ------------------------------------------------------------------------------ To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/