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