How do closed branches affect Mercurial performance?

Question

I've noticed that some answers to questions about branch names quote the Mercurial wiki to indicate that the branch-per-feature or branch-per-bug naming conventions may cause performance problems. Does the ability to mark branches as closed with the --close-branch flag on commits have any affect on this performance claim?

Answer 1

Does the ability to mark branches as closed with the --close-branch flag on commits have any affect on this performance claim?

Marking a branch closed with hg commit --close-branch merely creates a new changeset with a close=1 marker in the changeset meta data. Commands like hg branches and hg heads will then know not to show this branch/head. These commands use a branch cache to speed things up and we expect that cache to scale well with the number of branches.

However, there are some operations that have a complexity that is linear in the number of topological heads. This includes the discovery protocol used before version 1.9. The new discovery protocol in version 1.9 will still exchange topological heads in its "samples", but the sample size is capped at 200 changesets.

There might be other code paths that still scale linearly in the number of heads and this is why we suggest close-before-merge:

$ hg update bug-123
$ hg commit --close-branch -m "All fixed"
$ hg update default
$ hg merge bug-123

instead merge-before-close:

$ hg update default
$ hg merge bug-123
$ hg update bug-123
$ hg commit --close-branch -m "All fixed"

The latter approach leaves a dangling head in the graph (a topological head).

Answer 2

Close branch probably won't make any difference in performance, but that's not the point. The performance implications are small, and certainly not the reason I suggested you avoid permanent branch names for short-lived lines of development. Here's the relevant quote from the wiki:

Mercurial is designed to work well with hundreds of branches. It still works quite well with ten thousand branches, but some commands might show noticeable overhead which you will only see after your workflow already stabilized.

The reason both MG and I (we're the primary answerers in both of your linked questions) is because time and time again we watch people get really annoyed when they learn that branch names are permanent in Mercurial. Here's the usual exchange, that acts itself out in IRC a few times a week:

• Person A: "I've got 100 branches and I want to get rid of them!"
• Person B: "You can't. You can hide them, but Mercurial branches are forever."
• A: "But in git I have have 1000s of branches and get rid of them whenever I want!"
• B: "Yes, in Mercurial those are called bookmarks."

or similarly:

• Person C: "I named a branch 'stupid feature marketing made me add' and I want to push that change w/o pushing the branch name."
• Person B: "You can't. You can merge it into default, but that name is permanent on the changeset. You'd have to re-create the changeset to get rid of it!"
• C: "But in git my branch names are local only!"
• B: "Yes, in Mercurial those are called bookmarks."

If you want permanent, forever branch names on your changes (and MG, my co-answerer on both of those questions does like exactly that) then by all means use them, and don't worry a bit about performance. But do worry about how your tools represent the branches: like Mercurial itself, tools are typically built to scale in the number of changesets, not the number of branches. So they often do naive things like putting all branch names into a single drop-down menu. This GUI problem will eventually be fixed when named branches become more popular.

Steve Losh's excellent Guide to Branching in Mercurial does a great job spelling out your (four!) options. Pick what you like and be confident there are plenty of folks who like whichever one you selected, and at least a few of them have more branches than you ever will.