Comparing rebase --am with --interactive via p3400
- Date: Fri, 1 Feb 2019 07:04:31 +0100 (STD)
- From: Johannes Schindelin <Johannes.Schindelin@xxxxxx>
- Subject: Comparing rebase --am with --interactive via p3400
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.
My conclusion after seeing these numbers is: the interactive rebase is
really close to the performance of the --am backend. So to me, it makes a
total lot of sense to switch --merge over to it, and to make --merge the
default. We still should investigate why the split-index performance is so
significantly worse, though.