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

From: Jeff King <peff@peff.net>
Date: Jan 19, 2016, 22:48 UTC
Message-ID: <20160119224857.GD6556@sigill.intra.peff.net>
In-Reply-To: <20160119222802.GC6556@sigill.intra.peff.net>

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

Show 9 quoted lines

> 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