As with a lot of developer tools, the most adopted solutions are rarely the best tool for the job. But because everyone knows them, thats what continues to be used.
Moving to a continuous, asynchronous strategy versus a point-in-time synchronous strategy, seems like a perfectly reasonable way to improve performance.
All file operations involving many small files are slow on Windows, that's hardly git's fault. It can just do its best to work around the problem (for instance with this file watcher thingy).
Yes. Or they could just a different kind of SCM that doesn't have these performance issues.
I don't think that's so easy. For SVN we also saw a >10x performance difference between checking out the same repository on Linux vs Windows (however, after initial checkout, performance scales mostly with the number of changes, not the repository size).
so what is?
I don't know their use case very well.
Maybe Perforce. Or didn't MS have their own in-house SCM as well?