[ulyssesgrant]

Yes! I primarily develop on Linux, but lately have been working on Windows porting. In many ways the WSL has been a massive savior. It makes developing on Windows at least possible for Linux users. But it's sooo slooow.

The performance bottlenecks I hit seem to be disk i/o related. Things from path tab completion on the command line, to Vim's YouCompleteMe compiling code in the background, to a plain "git status", are just painfully slow right now.

If Microsoft can fix these performance issues, and someone ships a better terminal replacement (currently using ConEmu, also has issues), developing on Windows would be almost painless for Linux users (after learning how to integrate projects with Visual Studio...though I've read VS 2017 has better cmake integration).

[tobias3]

I'd say you pin can pin it down mostly to those reasons:

* Do you have active snapshots (vssadmin list shadows)? Halves random writes to disk in the worst case.

* Do you have USN journaling enabled (fsutil usn queryjournal c:)? Adds extra IO to meta-data operations.

* NTFS/FAT is optimized for fast directory listing speed so modifying files also modifies directory entries. Nothing one can do about that (except being aware of that and designing programs with this in mind).

* Windows doesn't keep as much dirty fs data in fs-cache. I know of no way to change that. One can probably, if one uses a Windows Server OS.

* Is a on-access Virus scanner active? If yes, one cannot compare performance to Linux. It's a massive bottleneck.

[nikbackm]

Regarding the last point.

Windows Defender will normally be active by default on Windows 10 unless you go out of your way to turn it off.

[hypervis0r]

It's not like editing a value in the registry is "going out of your way", it's almost standard Windows practice by now.

[joombaga]

Literally two commands in an elevated command prompt

    sc config WinDefend start= disabled
    sc stop WinDefend

[kalmi10]

The WinBtrfs project is very promising. I tried it a few days ago. I mounted my btrfs partition with it, and it appeared in /mnt under WSL. I chrooted into it from WSL, and it felt faster than the ntfs-backed linux fs. WinBtrfs has plans for implementing WSL permission pass-through. I look forward to that.

[oneweekwonder]

Tried https://mremoteng.org/ before? IIRC it wraps putty/kitty for ssh. But was the most useful terminal replacement options for me when I was on Microsoft Land.

[H1Supreme]

Git Bash works great for SSH too. Putty sucks, imo. Especially, the bullshit associated with the certificates. Git Bash uses Linux style rsa keys.

[josteink]

> If Microsoft can fix these performance issues, and someone ships a better terminal replacement (currently using ConEmu, also has issues)

wsl-terminal works for me.

https://github.com/goreliu/wsl-terminal

[ikurei]

> The performance bottlenecks I hit seem to be disk i/o related.

Would it be possible to mount the folders with the code on RAM? They aren't, usually, very heavy. May be a small-ish 500mb volume on RAM could help? Is this even possible on WSL/Windows?

[Tuna-Fish]

It's possible, but it wouldn't help. The problem is all the metadata lookups, which generally take several orders of magnitude more time on Windows than they do on Linux. The Windows implementation of NTFS just really isn't optimized to act as an unix filesystem.

[throwaway613834]

Do you know what exactly the fundamental barrier to this is? I've always wondered. What's so different about Linux and Windows that Windows has to do so much more work for file creation/deletion? It seems to be half an NTFS issue and half a Windows issue, because even on Linux I'm pretty sure NTFS is noticeably slower than ext[234], but not as slow as on Windows.

[Tuna-Fish]

I doubt there is any actual fundamental barrier, rather the reason is simply that the primary workload that Linus himself runs benefits greatly from faster metadata lookups, and therefore every nook and cranny of it has been optimized to as fast as possible.

In contrast, while metadata performance is sluggish in NTFS, at least a few years ago there were ways to get better large transaction async file performance than ext4 if you knew what you were doing -- clearly that workload was something that customers had asked for.

[buckminster]

Yes, SQL Server was that customer.