On: Improve Git monorepo performance with a file syste...

[gpderetta]

More likely the linux fs is fast enough not to need the optimization. Unsurprisingly git was designed to run well on linux .

[nasretdinov → gpderetta]

Not sure why the response got downvoted. I personally found Git performance to be, well, okay on macOS (but depends) and absolutely horrible on Windows due to very slow stat() calls on NTFS.

Of course, in a large enough monorepo Linux performance would also suffer, but to a much lesser degree.

Also, conveniently, both Windows and macOS have an API for recursive directory watch, whereas Linux doesn't (in Vanilla kernel). Inotify can only watch the immediate directory you're observing + there's a pretty low default limit on the number of inotify descriptors that you're allowed to have on top of that

[somekyle → gpderetta]

We've found this to be basically true. Git operations that stat() a lot are dramatically, catastrophically slower on OS X, and that's part of why my employer started doing fs watching there and mostly left Linux as is. More than once I've had to update a cross-platform tool to avoid stat()ing because though cheap on Linux, it took 10s of seconds on OS X.

[glandium → gpderetta]

You're most probably right.

  $ time git status
  real 0m0.324s
  user 0m0.197s
  sys 0m0.425s

That's on a working tree with 314,708 files and no watchman.

[bobkazamakis → gpderetta]

yeah it uses famous linux-exclusive data structures, like hashes and strings.

[wtetzner → bobkazamakis]

It's not the data structures, it's the file system operations.