On Sun, 10 Jun 2007, Sam Vilain wrote:
Now I'm not an expert on compression algorithms but I think a large part
of the reason gzip is blindingly faster than bzip2 is because gzip uses
a 64k buffer and bzip2 a 900k one. Only now are CPUs getting caches
large enough to deal with that size of buffer, the rest of the time
you're waiting for your RAM. Moore's law was supposed to make bzip2 fast
one of these days but I'm still waiting.
Anyway it's a free world so be my guest to implement it, I guess if this
was selectable it would only be a minor annoyance waiting a bit longer
pulling from from some repositories, and it would be interesting to see
if it did make a big difference with pack file sizes.
It won't happen for a simple reason: to be backward compatible with
older GIT clients. If you have your repo compressed with bzip2 and an
old client pulls it then the server would have to decompress and
recompress everything with gzip. If instead your repo remains with gzip
and a new client asks for bzip2 then you have to recompress as well
(slow). So in practice it is best to remain with a single compression
method.
Nicolas