I don't think he was talking about performance. I think he meant lightweight in the sense that a branch (in git) is just a pointer to a commit.

It's conceptually lightweight.

Both: it's conceptually lightweight, and because of that "pointer to a commit" structure it's also effectively free to create and move around branches.

Why is mercurial branches ineffective to move around branches? If I'm not mistaken, if you want to move commits from one branch to another you do absolutely the same rebase.

Well, mercurial branch is just a record in list of branches, so is it then also "conceptually lightweight"? What is "conceptually lightweight" anyway?

According to #mercurial, branches (even closed ones) begin to noticeably slow down the repository when you reach around 2000. That's not at all impossible to reach with fine-grained feature branches. Bookmarks are really just pointers to commits, no branches in any sense, so they cannot be used for feature branches either. As a result, we simply don't use feature branches in Mercurial. It's literally the only issue I can think of.

Not true any longer.

As described in http://mercurial.808500.n3.nabble.com/named-branches-vs-book...

> We have users with thousands of named branches in production and have > done tests on up to 10k branches and the performance impact is fairly > minimal.

Well, if that true, I'd prefer to investigate and make them fast, instead of using "bookmark-as-a-branch" because of all the cool stuff mercurial branches have (like great log-drawing with branch info).