On Mon, Oct 21, 2019 at 04:04:22PM -0700, Elijah Newren wrote:

> > 4211.3: git log --follow [...]8.56(8.41+0.15) -0.2%       3.67(3.53+0.13) 
> > -57.2%
> Many nice speedups here, not just commit-graph (the rev-list cases)
> but also log -L (from sg/line-log-tree-diff-optim, I believe), and log
> --follow.  I'm curious if the log --follow speedup comes from sg's
> series or something else...

The "log --follow" speedup comes from turning on commit-graphs. You can
see a similar effect without "--follow", since "git log <path>" is going
to be dominated by the commit traversal, and not accessing the trees
(especially if <path> is at the top-level).

> > 0001.9: rev-list --objects $commit --not --all                
> > 0.08(0.05+0.03)       0.08(0.05+0.03) +0.0%       0.09(0.07+0.02) +12.5%
> Looks like this one increased too, with a similar magnitude to the
> 7300.2 you pointed out.  But the base is kinda small; is this just
> noise?

Probably. I also frequently run the perf suite between major version
releases, and this kind of noise is quite common.

> I'm also curious what change it was that made these rebase tests faster.

Perf changes of this magnitude are usually pretty easy to bisect. You
can even do:

  git bisect start --term-old=slow --term-new=fast

so you don't have to confuse yourself with opposite good/bad markers.
I just ran:

  make && (cd t/perf && GIT_SKIP_TESTS=p3400.[3456] ./p3400*)

at each stopping point and eyeballed the resulting time (which for some
reason seems to be about 10x faster than Stolee's machine, but does
still show the same relative speedup). I was surprised that this also
yields 31b1de6a09 (commit-graph: turn on commit-graph by default,
2019-08-13). I wouldn't have expected commit access to dominate the
rebase time so much.


Reply via email to