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

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Feb 1, 2019, 07:22 UTC
Message-ID: <nycvar.QRO.7.76.6.1902010819470.41@tvgsbejvaqbjf.bet>
In-Reply-To: <nycvar.QRO.7.76.6.1901312310280.41@tvgsbejvaqbjf.bet>

Hi Elijah,

On Fri, 1 Feb 2019, Johannes Schindelin wrote:

Show 20 quoted lines

> 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