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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
