I totally agree with your conclusion but I wanted to comment about the IO performance remark. If you take an IO-heavy application and compile it natively on both platforms you will find that IO performance on Linux is dramaticly faster than windows(1) (and OSX for that matter). For certain workloads, I could see a Windows application running faster under emulation on Linux than natively.
1) This is maybe not true for big databases since those are optimized to basically bypass all of the Windows filesystem.
Is there any particular reason why Linux IO is dramatically faster? NTFS is polished FS, Fat32 is extremely simple (may be unreliable but that's not the point) and both should be performant enough. Also there's new ReFS. May be there's some stupid bug like Windows Defender checking file for viruses every write() call which could be easily fixed?
It's the general overhead and speed of syscalls for reading and writing files. It's very noticeable in software like git which works by reading and writing hundreds of small chunk files to disk. This is a well known fact and there's no way the team responsible for Windows filesystems is unaware. I would be shocked if it were possible to fix with a small or non-breaking change.
Isn't it a programming model thing? There's no Linux version of IOCP, and my impression is Windows apps that do use IOCP get good performance—but apps using cross-platform APIs or ported from UNIX tend not to have an IOCP-shaped IO layer and just use blocking calls, which are less optimized on Windows.
Maybe I'm confusing this with subprocess creation speed (which also hurt git back when lots of tools were shell or Perl scripts) or network performance (many years ago, my boss and I found that Apache on Linux on VMware Workstation on Windows with bridged networking performed better than Apache directly on Windows, presumably because it's using select() or something)?
I read previously on HN that it has something to do with NTFS's MFT structures... particularly when large number of small files are involved. I don't think FAT32 suffers from the same problem but then again, it isn't widely used on desktops or servers any more.
It's certainly also ACL overkill. They lookup ACL inheritance by default on every single file call, unless you turn it off in your directory. That's uncached and recursive up to the root, extremely slow.
Thanks for that info! It seems particularly noticeable in WSL when compiling large packages; all the dependency calculations are super slow compared to native Linux. I'd naively thought it had something to do with Windows Defender overhead but your explanation makes more sense.
1) This is maybe not true for big databases since those are optimized to basically bypass all of the Windows filesystem.