Not the biggest issue of them, 'find' and 'git status' on WSL2 in a big project is still >100 times slower on windows dev drive which avoids those filters than it is with WSL 1 on dev drive.
WSL 1 on regular ntfs with defender disabled is about 4x slower than WSL1 on dev drive, so that stuff does cause some of it, but WSL2 feels hopelessly slow. And wsl 2 can't share memory as well or take as much advantage of the filesystem cache (doubling it if you use the windows drive in both places I think, unless the network drive representation of it doesn't get cached on the WSL2 drive.
WSL2, in my testing, is orders of magnitude faster at file heavy operations than anything outside WSL, dev drive or not. We have an R&D department that's using WSL2 and jumping through hurdles of forwarding hardware because it's night and day compared to trying under windows on the same machine. It provided other benefits too, but the sheer performance was the main selling point.
WSL2 does not take less advantage of filesystem caches. Linux's block cache is perfectly capable. HyperV is a semi-serious hypervisor, so it should be using a direct I/O abstraction for writing to the disk image. Memory is also balloning, and can dynamically grow and shrink depending on memory pressure.
Linux VM's is something Microsoft has poured a lot of money into optimizing as that's what the vast majority of Azure is. Cramming more out of a single machine, and therefore more things into a single machine, directly correlates with profits, so that's a heavy investment.
I wonder why you're seeing different results. I have no experience with WSL1, and looking into a proprietary legacy solution with known issues and limited features would be a purely academic exercise that I'm not sure is worth it.
(I personally don't use Windows, but I work with departments whose parent companies enforce it on their networks,
> Linux's block cache is perfectly capable. HyperV is a semi-serious hypervisor, so it should be using a direct I/O abstraction for writing to the disk image.
Files on the WSL2 disk image work great. They're complaining about accessing files that aren't on the disk image, where everything is relayed over a 9P network filesystem and not a block device. That's the part that gets really slow in WSL2, much slower than WSL1's nearly-native access.
> Memory is also balloning, and can dynamically grow and shrink depending on memory pressure.
In my experience this works pretty badly.
> a proprietary legacy solution with known issues and limited features
Well at least at the launch of WSL2 they said WSL1 wasn't legacy, I'm not sure if that has changed.
But either way you're using a highly proprietary system, and both WSL1 and WSL2 have significant known issues and limited features, neither one clearly better than the other.
> WSL2 does not take less advantage of filesystem caches.
My understanding is when you access files on the windows drive, the linuxvm in WSL2 caches it in its own memory, and the windows side caches it in its: now you have double the memory usage on disk cache where files are active on both, taking much less advantage of caches than if you had used WSL1 where windows serves as the sole cache for windows drives.
I'm only comparing working on windows filesystems that can be accessed by both. My use case is developing on large windows game projects, where the game needs the files fast when running, and WSL needs the files fast when searching code, using git, etc. WSL1 was usable on plain NTFS, and now much closer to ext4 with dev drive NTFS. WSL2 I couldn't make fast.
You could potentially have the windows files on a network drive on the WSL2 side living in native ext4, but with that you get the double filesystem caching issue, and you might slow a game editor launch on the windows side by way too much, your files are inaccessible during upgrades and you have to always have RAM dedicated to WSL2 running to be able to read your files. MS store versions of WSL2 will even auto upgrade while running and randomly make that drive unavailable.
Running WSL2 on Dev Drive means that you're effectively doing network I/O (to localhost); of course it's slow. It's also very pointless since your WSL2 FS is already a separate VHD.
Not pointless if you are working on a windows project but using unix tools to search code, do commits, etc. WSL2 just isn't usable for it in large projects. git status can take 5 minutes on unreal engine.
I don't need just stock commandline tools, I use Claude Code etc. Maybe it can work in msys2 (it uses node) but it works well in WSL1. Also do a good bit with Python where some dependencies haven't worked in msys2.
I do windows and android gamedev and the server side is Linux.
However, WSL1 is pretty much abandoned and lots of newer distros have moved to forcing systemd or container based stuff that doesn't work in it, and some elf binaries no longer work in it (including newer node.js versions).
I use WSL2 as well when I really need it to be Linux and am doing webdev or something.
I use msys2 for a few things, usually compiling windows dependencies with the gnu toolchain that need GCC's stuff like inline assembly or computed goto (codecs etc.). Maybe possible from wsl1 too but they usually have full build and dependency instructions for msys2.
Not the biggest issue of them, 'find' and 'git status' on WSL2 in a big project is still >100 times slower on windows dev drive which avoids those filters than it is with WSL 1 on dev drive.
WSL 1 on regular ntfs with defender disabled is about 4x slower than WSL1 on dev drive, so that stuff does cause some of it, but WSL2 feels hopelessly slow. And wsl 2 can't share memory as well or take as much advantage of the filesystem cache (doubling it if you use the windows drive in both places I think, unless the network drive representation of it doesn't get cached on the WSL2 drive.