Re:MinC Is Not Cygwin
by adgjlsfhk1 on Wednesday April 23, 2025 @10:21AM
(#43772573)
I do think that talk is way too kind to the windows design. they're trying to make the argument that windows filesystem isn't slow, but the talk is how fixing the problem took 3 months of optimization and direct help from Microsoft. all of this could be avoided if Microsoft made their filesystem not ridiculously slow
NTFS/ReFS are not slow. But there is an extensible file system filter layer above them that can slow things down.
microsoft introduced Dev drives for this reason, they are optimized such that no file system filters are attached
I thought by filters they quite literally mean the antivirus filters in Defender? Does it strip down some of the Windows file semantics too?
File system filters are pluggable kernel drivers. For example, ProcMon (Sysinternals tool) monitors file systems via a file system filter -- so fun fact, if you outright disable file system filters on a ReFS volume, you won't get any ProcMon results! This was a 'duh' moment for me.
https://learn.microsoft.com/en-us/windows-hardware/drivers/i...
For example, if you were a Unix archiver extracting a file, you'd call stat() open() write() close() chmod() utimes(). On Linux/BSD that's 1 file open/close, but on Windows, that's 4 file opens/closes because the Windows APIs need an open filehandle, while the POSIX APIs take a filepath. Linux/BSD have LRU caches of filepath->inode because they're designed around these APIs, Windows doesn't. Cygwin has to open/close a Windows filehandle each time because it can't make the calling code pass a filehandle instead.
So it may be more comfortable and familiar, but also Windows APIs are unsympathetic to code designed for Unix originally.
See this talk on how the developers of rustup massively improved their performance on Windows by restructuring their code: https://www.youtube.com/watch?v=qbKGw8MQ0i8