I remember this issue (I commented in it a few years ago).
On the bright side, WSL as a development environment is no longer slow when it comes to real world usage. I've been using it for full time web app development for the last year and even made a video about my entire set up and configuration a week ago[0].
For example with WSL you can easily get <= 100ms code reloads even through a Docker for Windows volume on really big applications with thousands of files, such as a Rails app.
Even compiling ~200kb of SCSS through a few Webpack loaders (inside of Docker with a volume) takes ~600ms with Webpack's watcher. It's glorious.
I haven't had a single performance issue with a bunch of different Rails, Flask, Node, Phoenix and Jekyll apps (with and without Webpack). This is with all source code being mounted in from a spinning disk drive too, so it can get a lot faster.
So while maybe in a micro-benchmark, the WSL file system might be an order of magnitude slower (or worse) than native Linux, it doesn't really seem to matter much when you use it in practice.
> with WSL you can easily get <= 100ms code reloads even through a Docker for Windows volume
(Edited after watching your video.)
In your video it looks like you're running things in Docker containers. Even if you start containers using WSL, they still run in a separate Hyper-V virtual machine with a true Linux kernel, whereas WSL shares the Windows kernel and works by mapping Linux system calls directly to Windows kernel calls. When you run the "docker" command in WSL, it's just communicating with the Docker daemon running outside of WSL.
Docker runs this way on Windows because WSL does not implement all the Linux kernel system calls, only the most important ones needed by most applications, and the missing ones include some needed to run the Docker daemon.
All in all, this means that what you're talking about is not affected by the linked issue because it uses a different mechanism to access files (the Hyper-V driver rather than the WSL system call mapping). Although, if anything, I would expect Hyper-V to be even slower.
(Your edit makes my reply make a lot less since since you removed all of your original questions, but I'll leave my original reply, read the part after number 7)
My set up is basically this:
1. I use WSL as my day to day programming environment with the Ubuntu WSL terminal + tmux[0]. It's where I run a bunch of Linux tools and interact with my source code.
2. I have Docker for Windows installed (since the Docker daemon doesn't run directly in WSL yet due to missing Linux kernel features like iptables, etc.).
3. I installed Docker and Docker Compose inside of WSL but the daemon doesn't run in WSL. I just use the Docker CLI to communicate with Docker for Windows using DOCKER_HOST, so docker and docker-compose commands seamlessly work inside of WSL from my point of view[1].
4. All of my source code lives on a spinning disk drive outside of WSL which I edit with VSCode which is installed on Windows.
5. That source code drive is mounted into WSL using /etc/wsl.conf at / (but fstab works just as well)[2].
6. That source code drive is also shared with Docker for Windows and available to be used as a volume in any container.
7. All of my Dockerized web apps are running in Linux containers, but using this set up should be no problem if you use Windows containers I guess? I never used Windows containers, but that seems out of scope for WSL / Docker CLI. That comes down to Docker for Windows.
But, it's worth mentioning I have installed Ruby directly in WSL and didn't use Docker, and things are still just as fast as with Docker volumes. In fact, I run Jekyll directly in WSL without Docker because I really like live reload and I couldn't get that to work through Docker. My blog has like 200+ posts and 50+ drafts, and if I write a new blog post, Jekyll reloads the changes in about 3 seconds, and that's with Jekyll-Assets too. I have a feeling it wouldn't be that much faster even on native Linux since Jekyll is kind of slow, but I'm ok with a 3 second turn around considering it does so much good stuff for me.
It's worth noting that copying in/out of the docker for windows container can be interesting. Docker for windows mirrors the content in the volume directory on windows to one native inside the container... for some editing, it's fine... but try something a SQLite database with a gui in windows, and a container in linux both connected, and it will blow up on you.
The mount in WSL is really adaptive calls to the native OS, so that side will work without issue... the sync inside the container while editing is fast enough, and the running/building in the container is faster than it would be on the WSL itself as described by GP.
Are you talking about running it from the command line?
I use Git almost every day and have it installed directly inside of WSL.
It's not slow for any projects I've worked on, but it's worth mentioning I'm not dealing with code bases with millions of lines of code and many tens of thousands of files.
Most of the code bases I work on have ~100kb LOC or less (most are much less), and hundreds or low thousands of files.
Grepping through 50,000+ files through a WSL mount on a non-SSD is pretty slow, but I haven't tried doing that on a native Linux system in a long time so I can't really say if that slowness is mostly WSL or grepping through a lot of files in general.
If grep is hitting 100% utilization and isn't just file system bound, and you are dealing with ascii stuff, you can speed it up a lot of times by prepending 'LANG=C', so that it doesn't have to deal with unicode.
It rather depends on what "in practice" means in practice, though. I occasionally look at it with a test dominated by building small C programs and WSL remains several times slower than a Linux/ext4 install on the same hardware
Runtime on a Linux desktop machine is about 20 minutes. The point is that it's a workload dominated by small file operations, and in particular small file stat operations, that WSL is particularly bad at. And really it's not so crazy a workload.
My test is that W10 take half hour every time that I start it, hitting very hard the hard disk and being barely usable.
However I get ready to work on Ubuntu on less that a minute.
On the bright side, WSL as a development environment is no longer slow when it comes to real world usage. I've been using it for full time web app development for the last year and even made a video about my entire set up and configuration a week ago[0].
For example with WSL you can easily get <= 100ms code reloads even through a Docker for Windows volume on really big applications with thousands of files, such as a Rails app.
Even compiling ~200kb of SCSS through a few Webpack loaders (inside of Docker with a volume) takes ~600ms with Webpack's watcher. It's glorious.
I haven't had a single performance issue with a bunch of different Rails, Flask, Node, Phoenix and Jekyll apps (with and without Webpack). This is with all source code being mounted in from a spinning disk drive too, so it can get a lot faster.
So while maybe in a micro-benchmark, the WSL file system might be an order of magnitude slower (or worse) than native Linux, it doesn't really seem to matter much when you use it in practice.
[0]: https://www.youtube.com/watch?v=5gu8wWX3Ob4