[naikrovek]

> Windows coping very badly with development workloads like reading/writing many small files (which is a design flaw in the NT kernel and will not be fixed, ever).

Not the kernel, but ntfs.sys. It is a design limitation of NTFS and was a tradeoff for something else. At the time NTFS was designed, high frequency reading and writing to small files was not at all common.

This does not exist on FAT/32/64 partitions, though there is always a per-file overhead on any filesystem, and FAT filesystems have their own problems.

IO performance tools don't seem to test reading and writing to a large number of small files; they tend to want a single large file and they test performance to and from that file. That's by design, and that means those tools don't find filesystem design limitations, or allow you to measure certain types of performance on a per-filesystem basis.

> Edit: It shouldn't be a surprise that Visual Studio is essentially abandoned by Microsoft.

Again, not true.

No one can know everything that MS is doing, of course, but the number of people who think they do is quite high. I am not referring to the person who made the comment I am replying to, by the way. Generally I just see a lot of things about MS or MS tools that are stated as fact and are entirely incorrect.

[formerly_proven]

It's not (just) a NTFS problem, but larger design issues around the centralized object handling in NT, (intentional) lack of a caching VFS layer [1] and of course filter drivers (which are a public kernel API and enjoy a lot of use). There's a fairly lengthy explanation of these issues with Windows I/O somewhere on one of the WSL bug trackers.

> Again, not true. No one can know everything that MS is doing, ...

You're right of course - there is a number of releases yet to come. What I meant is that the focus is elsewhere (VS Code) and that the platform isn't going anywhere.

[1] In the design of typical unixen the file system is central and the kernel does a lot (central VFS, kernel resolves paths to inodes by itself if cached, in Linux the FS can even tell the kernel the extents of an inode to delegate that IO entirely etc.), while the NT design is a "generic tree of objects" (combined with "every action is an IRP, which can traverse any number of filters and such") where file systems are nothing really special; file system stuff is the file system's problem.