Git worktree performance impact

Question

I've just learned about the git worktree feature. It seems to fit my use-case well: I'm used to having a separate repo clone to do side tasks on.

I'm working in a big monorepo with lots of frequent commits and lots of files. It is so big that many tasks are slow. In particular, git fetch and git push, but even git status is no longer instantaneous.

So, git worktree sounds like a good idea, BUT it is absolutely not worth it if it impacts performance negatively in any noticeable way.

Are there commands or scenarios where multiple worktrees cause git to perform worse? For instance, does git fetch need to do more and thus take longer?

I am trying it out myself right now. But it is not easy to make precise performance comparisons. E.g., it is hard to do the same git fetch twice.

Answer 1

The worktree functionality in Git really shouldn't impact performance negatively in any meaningful way. The reason is that the worktree is basically just another working tree on an independent branch with its own index and possibly a small set of local configuration variables. All the references and objects are stored in and shared out of the main repository, so it doesn't matter there whether you use no worktrees or a hundred.

It may happen that if you work out of multiple worktrees at once that you will have worse performance because running git status in one worktree would evict cached metadata about the other worktree. However, you'd have that problem anyway but worse if you changed branches in the main repository, so I wouldn't consider that a serious problem.

Some people like using multiple worktrees and some don't. You may find it's a good fit for you or not, but I wouldn't worry about it in terms of performance.