Jeff King <> writes:

> If you have before-and-after numbers for just this patch on some
> repository, that would be an interesting thing to put in the commit
> message.

It's a hen-and-egg problem regarding the benchmarks.  The most
impressive benchmarks arise with the git-blame performance work in
place, and the most impressive benchmarks for the git-blame performance
work are when this or something similar is in place.  Of course, when
there are two really deficient things slowing operations down, fixing
only one is going to be much less impressive.

So I decided to tackle the low-hanging fruit here first.  But it would
appear that this amounts in far too much work since it means I have to
search for and create some _other_ benchmarking scenario not hampered by
substandard code like the current git-blame is.

I have enough on my plate as it is, so even though it puts the _real_
git-blame work in a worse light, I should rather get that finished first
(nobody will argue to keep the useless threshing of it around).  Of
course, the person then creating the two-line change to
deltaBaseCacheLimit will be able to claim much larger performance
improvements in his commit message afterwards than what I can claim
regarding the git-blame work when going first, but that's life.

David Kastrup
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to