Hacker News Reader

> 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.

[0]: https://nickjanetakis.com/blog/conemu-vs-hyper-vs-terminus-v...

[1]: https://nickjanetakis.com/blog/setting-up-docker-for-windows...

[2]: https://github.com/nickjj/dotfiles/blob/master/etc/wsl.conf

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.

Git runs really slow on it. It runs much faster when turning off Windows defender (but still slow).

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.

Its a project with several million lines of code.

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.

I'll throw in my vote to try something like ack / ag that have better defaults for code-grepping.

Here's some anecdata from my experience using git at work, where we have a single large repository for all projects.

Running `git status` in a Linux VM is fast (near-instant).

With the native Git for Windows, it's noticeably slower - maybe half a second - but still usable.

In WSL it takes around 10 seconds, which is just unusable for me.

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

But the point is that if your compilation time is less than eg 100ms on WSL, it doesn’t really matter if it’s 2 or 100 times slower than ext4.

Some people may have more than one test.

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.

I think it does because the difference adds up quickly with large projects

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.