Comment by binsquare
12 hours ago
Lot of the WSL2 lag is not the VM itself, it's the 9P file sharing and interop.
I found that seems like anything under /mnt/c goes through 9P
12 hours ago
Lot of the WSL2 lag is not the VM itself, it's the 9P file sharing and interop.
I found that seems like anything under /mnt/c goes through 9P
You’re not supposed to work out of the /mnt/c. A lot of people make this mistake and then complain that WSL is slow. On the native linux file system WSL is 100x faster for everything
On top of the performance issue you mentioned, /mnt/c will be case-insensitive and trip up lots of Linux software!
On my work laptop I made the lazy/naive mistake of mounting my projects from macOS into devcontainers running in Colima.
vscode extensions using ripgrep in parallel in the background (there are many!) are killing the vm.
I now decided to follow Mitchell Hashimoto choice and use VMware Fusion and simply do all my work inside of it.
That's the entire appeal of WSL (for me). A single source checkout I can work on from both sides; no inconsistency of forgetting that I need to apply changes twice.
Without it, I can just as well ssh into another box.
I've generally found it better to do it other way around - keep all the stuff in Linux partition and from Windows side access that over the virtual network share \\wsl.localhost\<Distro>\home\me\whatever
Trust me, its not worth the performance cost. Just use git push and pull across the /mnt/c boundry
I do this on wsl1 without issue. wsl2 has an experimental new virtual (or just remote?) fs you can enable but I have not tested it.
From the perspective of user empathy, wsl seems to be designed for that use case. but the implementation/defaults can be improved
I do not really follow how you would avoid this if you are using WSL containers with dev containers. Wouldn't this be the default?
>You’re not supposed to work out of the /mnt/c.
Source?
Microsoft now launches a pop-up discourging this, so that is my source. Also my own personal experience using WSL for 8 years.
You can very easily measure this as well, use any disk benchmark
There is virtio support now, and to be fair 9P was never an issue for me.
9P is very slow for certain operations (such as, for example, git from either direction).
virtio is not enabled by default because its buggy in certain corner cases, and will be enabled by default when it stops doing that. That said, I do have that enabled, it is certainly faster.
Since nowadays I use WSL to run immutable containers, and not really classical Linux Desktop, it isn't something that bothers me.
Agents take more time than building Docker images.
And yet I had results perfectly within the range of "good enough" having an ai harness muck about in a work folder in a docker mount on a 9P mapped drive under permanent observation by an intelliJ instance on the Windows side before some buggy Windows update made it occasionally lock up under `npm i` sized filesystem loads. Crazy how far we've come.
That feature is faster as well (using virtiofs instead of 9p), but i use the native VHDX IO for my work, which is adequately fast.