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 -- 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