On 2008.08.14 16:14:26 -0700, Linus Torvalds wrote:
quoted text
> 
> On Thu, 14 Aug 2008, Nicolas Pitre wrote:
> > 
> > Possible.  However, the fact that both the "Compressing objects" and the 
> > "Writing objects" phases during a repack (without -f) together are 
> > _faster_ than the "Counting objects" phase is a sign that something is 
> > more significant than cache misses here, especially when tree 
> > information is a small portion of the total pack data size.
> 
> Hmm. I think I may have clue.
> 
> The size of the delta cache seems to be a sensitive parameter for this 
> thing. Not so much for the git archive, but working on the kernel tree, 
> raising it to 1024 seems to give a 20% performance improvement. That, in 
> turn, implies that we may be unpacking things over and over again because 
> of bad locality wrt delta generation. 

Since you mention the delta cache, uau (no idea about his real name) on
#git was talking about some delta cache optimizations lately, although
he was dealing with "git log -S", maybe it affects rev-list in a similar
way. Unfortunately, I can't seem to find any code for that, just a
description of what he did and some numbers on the results in the IRC
logs.

http://colabti.org/irclogger/irclogger_log/git?date=2008-08-04,Mon#l65

Maybe that helps in some way.

Björn
--
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