Microsoft Still Working To Squeeze More I/O Performance Out Of WSL / Bash For Windows

[blacknova]

That certainly could have been true if NT would have been pure microkernel, but NT is hybrid and cache and i/o executives are running in kernel space. So I doubt there are much more context switches comparing to Linux. I'm not sure if win32 subsystem is still running in kernel-space for Windows 10 like it was in WinXP.

[Danielsan]

It seems like the history of Pinocchio inside the whale's stomach...

[edwaleni]

If you want good performance for WSL, create a partition to run WSL out of with System Restore, Indexing, and Compression disabled. Then it will be about 80% the speed of EXT4 on average.

I think this is what user starship was recommending after the last WSL test go around. Just like many corporations don't run AV on SQL Server volumes, turn off I/O robbing services from the WSL file system space.

[F.Ultra]

Maybe it has to do with the fact that it's a micro-kernel design and requires more context switches doing many-file operations (not just reads and writes but also open and close).

I doubt that context switching overhead would be so great that it could explain such a big performance penalty. I think that it's a combination of NTFS being just slow (I mean the internal structure of NTFS is way over engineered with multiple stream support and so forth) and that Windows kind of does something to keep the IO subsystem busy 24x7.

Now to be honest it was over 10 years since I saw a rack mounted Windows server, but back then when you walked into a server room at night when the servers where idling the activity leds for disk and network on the Linux and BSD servers where dark while the Windows machines light up like it was Christmas. If I'm not mistaken Windows have a tendency to prefer to put memory of running applications to swap as soon as possible which also would stress the IO subsystem more.

[nils_]

It seems like the history of Pinocchio inside the whale's stomach...

I don't think that's how it goes

[Palu Macil]

They really need to find a fix for directory traversal as well. "/path/to/softlink-dir/../" goes to the parent of the directory that softlink-dir points to, rather than to the parent directory of the softlink-dir. Has to do with how underlying NTFS deals with directory junctions.

Sure glad you mentioned this! I never would have believed it wasn't me just doing something wrong somewhere!

[Danielsan]

I don't think that's how it goes

The day that you will go to buy a computer or a laptop and the sales person starts to say that if you buy a computer with Win(X) you can have access to thousand Linux distros as well for free let me say if change your mind, please!

[carewolf]

You may find the same thing running a Linux VM on Windows. I ran the unit test suite for a web application (all Node stuff) in a VM with limited resources and it was 4-5x faster than on the Windows host. I think part of the problem is that Windows is a second class citizen for many open source projects (particularly developer-oriented ones), probably because the developers rarely run Windows themselves.

It is the file-system. Linux file-system and FS drivers are heavily optimized for development. I haven't tried the latest macOS FS, but it is supposed to be a lot faster than the old standard HFS(+).

[Weasel]

I doubt that context switching overhead would be so great that it could explain such a big performance penalty. I think that it's a combination of NTFS being just slow (I mean the internal structure of NTFS is way over engineered with multiple stream support and so forth) and that Windows kind of does something to keep the IO subsystem busy 24x7.

Now to be honest it was over 10 years since I saw a rack mounted Windows server, but back then when you walked into a server room at night when the servers where idling the activity leds for disk and network on the Linux and BSD servers where dark while the Windows machines light up like it was Christmas. If I'm not mistaken Windows have a tendency to prefer to put memory of running applications to swap as soon as possible which also would stress the IO subsystem more.

Don't forget that Windows is also case-insensitive, which is quite a pain to do for Unicode, not to mention NTFS can store two such files case-sensitively and so conflicts still exist (it's undefined which one gets picked by Windows). I guess looking up case-insensitively is a lot more work if you do millions of open() file operations (case sensitive on the other hand, like Linux, requires zero extra processing).

What I'm saying is, I doubt they (Microsoft) can make it (native NTFS, not WSL) much faster, and I doubt WSL will ever be faster than native (unless it directly uses special kernel calls, but I seriously doubt it, it's probably just a wrapper so it cannot be faster). Unless, unless, they wrote some shit unoptimized code in there, but I really doubt it after so many years.

It was a bad design from the beginning, and I heard macOS is also case-insensitive, except HFS+ is much, much worse of a mess than NTFS is. Always makes me facepalm. It's one thing where Unix and Linux got it right completely, full respect.

[duby229]

Hope they implement a proper X server next and provide a way to disable the win32 and win64 subsystem.

Oh god I wish there was a "hate" button too....