This is a follow up to part one.
For a while, git has supported an fsmonitor hook to allow running a process like watchman in the background to, well, watch for changes to files in the repo and report them back to git when they happen instead of git waiting to look for changes all at once after you call the status
command (like a sucker).
This was great in theory, but I had two problems with it when I tried it. First of all, setting it up was annoying! You had to decide which watchman-like tool to install, write (ok, copy and paste) a git hook to call it correctly and hope that you didn't break anything else along the way.
Second of all, and more importantly, it didn't make things any faster! I timed running git status
with and without the hook enabled, and never found much of an improvement. This was disappointing as I'd read everywhere how it was supposed to speed things up greatly.
However today I stumbled back upon git's fsmonitor settings and found out that a new version of git was released today (2022-06-27)—version 2.37.0—that includes a built in fsmonitor daemon, meaning that watchman and an fsmonitor hook are no longer needed to get the same behavior. I decided to give it a go by updating my git config:
git config --global core.fsmonitor true
I then ran git status
in my very large repo of choice once to get the daemon started, then again and wtf... it returned almost instantly? Doing the usual benchmarking confirmed it, git status
now returned just 84ms.
Remembering my previous failure to squeeze much performance out of using an fsmonitor, I wondering if this huge improvement was because of it being built in to git or because of something else, so I decided to test the three untracked file modes of git status
with and without the fsmonitor enabled.
untracked files | without fsmonitor | with fsmonitor |
---|---|---|
no | 179ms | 45ms |
normal | 279ms | 84ms |
all | 966ms | 827ms |
If you want a great visual comparison of what this kind of difference in latency looks like, check this out from @Piwai.
So it turns out that whatever the all
mode is doing under the hood must be cancelling out most of the speed gains from having the fsmonitor enabled, which explains why I never had great results with it in the past, since all
was enabled as the default!
Try it out and see if it helps in your local mongo repo.