On Sat, 12 Jan 2008, Sam Vilain wrote:

quoted text
> Linus Torvalds wrote:
> > 
> > On Fri, 11 Jan 2008, Sam Vilain wrote:
> >> The difference seems only barely measurable;
> > 
> > Ok. 
> > 
> > It may be that it might help other cases, but that seems unlikely.
> > 
> > The more likely answer is that it's either of:
> > 
> >  - yes, zlib uncompression is noticeable in profiles, but that the 
> >    cold-cache access is simply the bigger problem, and getting rid of zlib 
> >    just moves the expense to whatever other thing that needs to access it 
> >    (memcpy, xdelta apply, whatever)
> > 
> > or
> > 
> >  - I don't know exactly which patch you used (did you just do the 
> >    "core.deltacompression=0" thing?), and maybe zlib is fairly expensive 
> >    even for just the setup crud, even when it doesn't really need to be.
> > 
> > but who knows..
> 
> Well, my figures agree with Pierre I think - 6-10% time savings for
> 'git annotate'.
> 
> I think Pierre has hit the nail on the head - that skipping
> compression for small objects is a clear win.  He saw the obvious
> criterion, really.  I've knocked it up as a config option that doesn't
> change the default behaviour below.

Sorry to rain on your parade, but to me 6-10% time saving is not a clear 
win at all, given the equal increase in repository size.  This is simply 
not worth it.

And a 50% time saving on an operation, such a git log, which takes less 
than 2 seconds in absolute time, is not worth the repo size increase 
either.  Going from 2 seconds down to one second doesn't make enough of 
a user experience difference.

If git blame was to go from 10 seconds down to 4 then I'd say this is a 
clear win.  But this is not the case.


Nicolas
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html