Hm. Did you read the comment by the Microsoft dev in the linked thread? He gives the following reasons:
"We've long since gotten all the low-hanging fruit and are left with what is essentially "death by a thousand cuts," with no single component responsible for our (lack of) performance, but with lots of different things contributing"
* Linux has a top-level directory entry cache that means that certain queries (most notably stat calls) can be serviced without calling into the file system at all once an item is in the cache. Windows has no such cache, and leaves much more up to the file systems... [snip]
* Windows's IO stack is extensible, allowing filter drivers to attach to volumes and intercept IO requests before the file system sees them. ... [snip] .. Even a clean install of Windows will have a number of filters present, particularly on the system volume (so if you have a D: drive or partition, I recommend using that instead, since it likely has fewer filters attached). Filters are involved in many IO operations, most notably creating/opening files.
* The NT file system API is designed around handles, not paths. Almost any operation requires opening the file first, which can be expensive. ... [snip]
"Whether we like it or not (and we don't), file operations in Windows are more expensive than in Linux, even more so for those operations that only touch file metadata (such as stat)."
I can say my personal experience under Windows has been that compiling the same project was twice as fast in a linux virtualbox inside windows, than in the host. :)
"We've long since gotten all the low-hanging fruit and are left with what is essentially "death by a thousand cuts," with no single component responsible for our (lack of) performance, but with lots of different things contributing"
* Linux has a top-level directory entry cache that means that certain queries (most notably stat calls) can be serviced without calling into the file system at all once an item is in the cache. Windows has no such cache, and leaves much more up to the file systems... [snip]
* Windows's IO stack is extensible, allowing filter drivers to attach to volumes and intercept IO requests before the file system sees them. ... [snip] .. Even a clean install of Windows will have a number of filters present, particularly on the system volume (so if you have a D: drive or partition, I recommend using that instead, since it likely has fewer filters attached). Filters are involved in many IO operations, most notably creating/opening files.
* The NT file system API is designed around handles, not paths. Almost any operation requires opening the file first, which can be expensive. ... [snip]
"Whether we like it or not (and we don't), file operations in Windows are more expensive than in Linux, even more so for those operations that only touch file metadata (such as stat)."
I can say my personal experience under Windows has been that compiling the same project was twice as fast in a linux virtualbox inside windows, than in the host. :)