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.

Towney

See also "UNTRACKED FILES AND PERFORMANCE" with git status. – Rugger

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.

Songer

Answer 2

I recently encountered the observation that git fetch is mysteriously slower proportionate to the number of worktrees in a clone. This looks to have been addressed in git 2.37.

From the release notes:

• The way "git fetch" without "--update-head-ok" ensures that HEAD in no worktree points at any ref being updated was too wasteful, which has been optimized a bit. (merge f7400da800 os/fetch-check-not-current-branch later to maint). https://github.com/git/git/blame/master/Documentation/RelNotes/2.37.0.txt#L225-L228

(More details in the commit message: https://github.com/git/git/commit/f7400da800)

However this looks to be specifically relating to git fetch in git versions <2.37 so doesn't address your observations about other commands being slow.

Regarding:

it is hard to do the same git fetch twice.

You can use git fetch --dry-run to help with this.

Dutiful