Re: [PATCH 0/7] Optimization batch 14: trivial directory resolution

From: Elijah Newren <newren@gmail.com>
Date: Jul 1, 2021, 19:22 UTC
Message-ID: <CABPp-BH3H20wAoD4CJmQjj2iVhnXN+M=XvQdUWUgvY0VxPHKZw@mail.gmail.com>
In-Reply-To: <CABPp-BGRgL-SnHDgefq887e51z9t_TMXcc4DLrazggC-1iQWng@mail.gmail.com>

A small correction/clarification...

On Thu, Jul 1, 2021 at 8:04 AM Elijah Newren <newren@gmail.com> wrote:

Show 12 quoted lines

>
> On Thu, Jul 1, 2021 at 6:31 AM Ævar Arnfjörð Bjarmason <avarab@gmail.com> 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@gmail.com/#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.

Show 7 quoted lines

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