Why is mercurial's hg rebase so slow?

Question

The rebase extension to mercurial provides functionality similar to git's rebase.

Letting the rebase execute takes something like 4 minutes (~240 s) for 100 commits.

In my imagination this should be extremely fast, a few seconds at most, but clearly I'm missing something.

What makes it take so long? Are the commits themselves just extremely expensive?

Plausive

I suppose you'd have to construct identical test cases in hg and git to can an objective comparison. But IMHO with hg I do agree that rebasing is not fast. – Rathskeller

I've regularly rebased my changes of this size frequently and I faced similar slowdowns where there are blobs in the commits. Do you have blobs in your source branch/head that you are trying to rebase? Calculating the sha for blobs might be the killer here. – Studnia

@Studnia you mean like binary blobs? In the repo, there are probably somewhere. In the set of commits I'm rebasing, there are no binary blobs. – Plausive

Answer 1

By default, rebase writes to the working copy, but you can configure it to run in-memory for better performance, and to allow it to run if the working copy is dirty. Just add following lines in your .hgrc file:

[rebase]

experimental.inmemory = True

(To get more configuration for rebase try to run hg help rebase)

Busty

But why is writing to the working copy even slow? It would seem that it's way to slow to even be bottle necked by disk io unless there's a massive amount of io that I'm not thinking about, no? – Plausive

Interesting; I rebased about 70 changesets. I tried it both ways. This was initially MUCH faster - first 20 or so. Then it slowed down to seemingly normal. Still better overall. – Rathskeller

I see what happened. It sped along in memory until it hit a conflict; then it started over on disk instead, and it redid ALL the ones that had it gotten through before the conflict. – Rathskeller

I did another with 115 changesets - no conflicts - and it must have been ~5x faster. – Rathskeller