Re: [PATCH] filter-branch: resolve $commit^{tree} in no-index case

[Jeff King <peff@peff.net>]

On Tue, Jan 19, 2016 at 05:28:02PM -0500, Jeff King wrote:

> I dunno. I'm inclined to say that none of this is worth it to try to
> drop one or two processes. Writing filter-branch in a better language
> (or just using BFG) would probably be a more productive use of time.
> 20% looks like a lot, but that's because it's pretty fast in the first
> place.  The timings I showed earlier (and below) are for git.git, which
> is not that huge. But the savings from 348d4f2 are really about avoiding
> looking at the trees entirely; the bigger your tree, the more you save.
> Running it on linux.git should show that we're still reclaiming most of
> the original optimization.

In case anyone is curious, here are the linux.git numbers (re-wrapped,
because t/perf produces some really long lines; that might be worth
addressing):

348d4f2^ 295.32(269.61+14.36)
348d4f2    7.92(  0.85+ 0.72)    -97.3%
HEAD^      9.37(  0.87+ 0.80)    -96.8%
HEAD       7.71(  0.92+ 0.62)    -97.4%

So yes, the conservative fix costs us about 1.5 seconds, or 18%, over
the micro-optimized one.  But the original point was to save over 280
seconds, which we still do.

-Peff