On Sat, 12 Jan 2008, Sam Vilain wrote: > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
