Git and GCC

[Johannes Schindelin]

Hi,

On Fri, 7 Dec 2007, Daniel Berlin wrote:

> On 12/7/07, Giovanni Bajo <rasky@develer.com> wrote:
> > On Fri, 2007-12-07 at 14:14 -0800, Jakub Narebski wrote:
> >
> > > > >> Is SHA a significant portion of the compute during these 
> > > > >> repacks? I should run oprofile...
> > > > > SHA1 is almost totally insignificant on x86. It hardly shows up. 
> > > > > But we have a good optimized version there. zlib tends to be a 
> > > > > lot more noticeable (especially the *uncompression*: it may be 
> > > > > faster than compression, but it's done _so_ much more that it 
> > > > > totally dominates).
> > > >
> > > > Have you considered alternatives, like: 
> > > > http://www.oberhumer.com/opensource/ucl/
> > >
> > > <quote>
> > >   As compared to LZO, the UCL algorithms achieve a better 
> > >   compression ratio but *decompression* is a little bit slower. See 
> > >   below for some rough timings.
> > > </quote>
> > >
> > > It is uncompression speed that is more important, because it is used 
> > > much more often.
> >
> > I know, but the point is not what is the fastestest, but if it's fast 
> > enough to get off the profiles. I think UCL is fast enough since it's 
> > still times faster than zlib. Anyway, LZO is GPL too, so why not 
> > considering it too. They are good libraries.
> 
> 
> At worst, you could also use fastlz (www.fastlz.org), which is faster 
> than all of these by a factor of 4 (and compression wise, is actually 
> sometimes better, sometimes worse, than LZO).

fastLZ is awfully short on details when it comes to a comparison of the 
resulting file sizes.

The only result I saw was that for the (single) example they chose, 
compressed size was 470MB as opposed to 361MB for zip's _fastest_ mode.

Really, that's not acceptable for me in the context of git.

Besides, if you change the compression algorithm you will have to add 
support for legacy clients to _recompress_ with libz.  Which most likely 
would make Sisyphos grin watching them servers.

Ciao,
Dscho