Re: Comparing rebase --am with --interactive via p3400

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

Hi Elijah,

On Fri, 1 Feb 2019, Johannes Schindelin wrote:

> as discussed at the Contributors' Summit, I ran p3400 as-is (i.e. with the
> --am backend) and then with --keep-empty to force the interactive backend
> to be used. Here are the best of 10, on my relatively powerful Windows 10
> laptop, with current `master`.
> 
> With regular rebase --am:
> 
> 3400.2: rebase on top of a lot of unrelated changes             5.32(0.06+0.15)
> 3400.4: rebase a lot of unrelated changes without split-index   33.08(0.04+0.18)
> 3400.6: rebase a lot of unrelated changes with split-index      30.29(0.03+0.18)
> 
> with --keep-empty to force the interactive backend:
> 
> 3400.2: rebase on top of a lot of unrelated changes             3.92(0.03+0.18)
> 3400.4: rebase a lot of unrelated changes without split-index   33.92(0.03+0.22)
> 3400.6: rebase a lot of unrelated changes with split-index      38.82(0.03+0.16)
> 
> I then changed it to -m to test the current scripted version, trying to
> let it run overnight, but my laptop eventually went to sleep and the tests
> were not even done. I'll let them continue and report back.

It finally finished:

3400.2: rebase on top of a lot of unrelated changes             7.37(0.09+0.19) 
3400.4: rebase a lot of unrelated changes without split-index 393.96(0.04+0.15)
3400.6: rebase a lot of unrelated changes with split-index    404.65(0.01+0.24)

So there is a seemingly significant cost to using the split-index that is
just very unfortunate. In any case, just switching from the scripted
--merge backend to the built-in interactive backend results in a >10x
faster execution. So I *definitely* want that scripted `--merge` backend
to go away. Thank you for doing this.

Ciao,
Dscho