A small correction/clarification... On Thu, Jul 1, 2021 at 8:04 AM Elijah Newren <newren@xxxxxxxxx> wrote: > > On Thu, Jul 1, 2021 at 6:31 AM Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> wrote: > > > > On Thu, Jul 01 2021, Elijah Newren via GitGitGadget wrote: > > > > > This series depends textually on ort-perf-batch-12, but is semantically > > > independent. (It is both semantically and textually independent of > > > ort-perf-batch-13.) > > > > For others following along, that ort-perf-batch-12 is at > > https://lore.kernel.org/git/pull.962.v4.git.1623168703.gitgitgadget@xxxxxxxxx/#t > > & currently marked as 'will merge to next' in what's cooking. Yeah, I should have referred to it as en/ort-perf-batch-12, the branch name Junio used. > Granted, merge-recursive doesn't take quite as long as it used to; it > also benefited from some of my optimizations[1]. Nowhere near as much > as merge-ort benefited, but it still would be about 20x faster on the > cases with "mega" in their name. So, although today's merge-ort is > ~5542.7x faster than git-2.29.0's merge-recursive for a massive set of > renames in a really long rebase sequence, it is probably only a mere > 277x faster than today's merge-recursive on the same case. The 20x number here I was just spit-balling, whereas the other numbers were measured. I think 20x may have been a bit too high. Regardless, though, to me the important takeaway is not the performance difference between merge-ort and merge-recursive now (though that's also huge in merge-ort's favor), but between merge-ort now and merge-recursive when I started. If someone really wants me to get the difference between the two now, I can dig in, but it's annoyingly painful waiting for merge-recursive to finish tests several times.
