Re: [PATCH 0/5] tree-walk object_id refactor

From: Jeff King <peff@peff.net>
Date: Jan 11, 2019, 14:17 UTC
Message-ID: <20190111141753.GA16754@sigill.intra.peff.net>
In-Reply-To: <20190111001750.GO423984@genre.crustytoothpaste.net>

On Fri, Jan 11, 2019 at 12:17:50AM +0000, brian m. carlson wrote:

Show 9 quoted lines

> > I think this is really the only safe and sane solution. We resisted it
> > because of the cost of the extra copies (especially the
> > update_tree_entry() one). But I don't know that anybody actually
> > measured it. Do you have any performance numbers before/after this
> > series?
> 
> Unfortunately, I don't. I'm not really sure in what situations we hit
> this code path a lot, so I'm not sure what exactly we should performance
> test. If you have suggestions, I can set up some perf tests.

I think the interesting one here is the copy in update_tree_entry(), which is called for every entry of every tree we parse for a diff. So the command with the most noticeable impact, I think, would be something like:

  git log -- pathspec

I couldn't demonstrate any measurable slowdown (I didn't compute the mean to see if it gets worse, but certainly any change is within the run-to-run noise).

I guess that is competing with the cost to access the commit objects. Perhaps a pure tree diff would be a more precise test. Here's the most pathological case I could come up with:

  git init
  for i in $(seq 10000); do echo $i >$i; done
  git add .
  git commit -m base
  echo change >9999
  git commit -am change
  time git diff-tree HEAD^ HEAD

which should really be spending 99% of its time inflating and walking through the trees. And even there I couldn't measure anything.

So I'd say it's probably fine.

-Peff