On Mon, Jun 04, 2007 at 09:31:24PM -0400, Simon wrote: > On 6/2/07, Roberto C. Sánchez <[EMAIL PROTECTED]> wrote: > >Because on some architectures, there are not 2 GHz dual-core or > >quad-core CPUs available. Making them take double or triple the time > >for a 10% gain space is probably not acceptable. > > It's not about saving space, it's about handling upstream release > archives with a minimum of modifications. I agree about the > performance concerns, and gzip has a very high performance to > compression rate ratio, but handling upstream files unmodified saves > developers time, and avoids the confusion about the origin of a > tarball. >
Yes. But then what of projects like OpenOffice.org and gcc? OOo releases their sources in .tar.bz2 files of the following sizes: 117 MB, 28 MB, 16 MB, 70 MB and 28 MB. Gcc releases their sources in .tar.bz2 files of the following sizes: 42 MB, 4 MB, 18.1 MB, 957 KB, 5 MB, 10 MB, 193 KB, 4 MB. Now, according to http://db.debian.org/machines.cgi, the arm and m68k machines avaiable are: elara - (206 MHz StrongARM, 64 MB RAM) europa - (206 MHz StrongARM, 128 MB RAM) leisner - (184 MHz ARM, 60 MB RAM) kullervo - (50 MHz 68060, 112 MB RAM) I am relatively certain that on those machines, the speed boost of using gzip compression over bzip2 compression is probably quite necessary in the ability of those machines which are being used as buildds to keep up. If you search for gzip bzip2 comparisons or benchmarks you will also see, that depending on the benchmark and the files tested, bzip2 can take a great deal longer (some bench marks reported times of up to triple that of gzip) to decompress with bzip2. In addition, bzip2 hogs memory. One benchmark [0] on the OOo 1.1.4 sources showed that when using compression level 9, the sources compressed to 78768334 bytes for gzip and 72223858 for bzip2 (a savings of ~6 MB). However, the decompression time was 38.2s for bzip2 and 3.1 seconds for gzip. That is a difference of more than order of magnitude. The difference for the Linux 2.6.11 sources was even bigger! To say nothing of the fact that bzip2 required about quadruple the amount of memory on decompression. Regards, -Roberto [0] http://tukaani.org/lzma/benchmarks -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com
signature.asc
Description: Digital signature