Re: [PATCH 4/4] mark_parents_uninteresting(): avoid most allocation

From: Jeff King <peff@peff.net>
Date: May 14, 2018, 13:09 UTC
Message-ID: <20180514130907.GB9219@sigill.intra.peff.net>
In-Reply-To: <8447da69-d28a-433c-f324-a6380b6ca991@gmail.com>

On Mon, May 14, 2018 at 08:47:33AM -0400, Derrick Stolee wrote:

Show 18 quoted lines

> On 5/11/2018 2:03 PM, Jeff King wrote:
> > Commit 941ba8db57 (Eliminate recursion in setting/clearing
> > marks in commit list, 2012-01-14) used a clever double-loop
> > to avoid allocations for single-parent chains of history.
> > However, it did so only when following parents of parents
> > (which was an uncommon case), and _always_ incurred at least
> > one allocation to populate the list of pending parents in
> > the first place.
> > 
> > We can turn this into zero-allocation in the common case by
> > iterating directly over the initial parent list, and then
> > following up on any pending items we might have discovered.
> 
> This change appears to improve performance, but I was unable to measure any
> difference between this commit and the one ahead, even when merging
> ds/generation-numbers (which significantly reduces the other costs). I was
> testing 'git status' and 'git rev-list --boundary master...origin/master' in
> the Linux repo with my copy of master 70,000+ commits behind origin/master.

I think you'd want to go the other way: this is marking uninteresting commits, so you'd want origin/master..master, which would make those 70k commits uninteresting.

I still doubt it will create that much difference, though. It's more or less saving a single malloc per commit we traverse. Certainly without the .commits file that's a drop in the bucket compared to inflating the object data, but I wouldn't be surprised if we end up with a few mallocs even after your patches.

Anyway, thanks for poking at it. :)

-Peff