![]() Sadly that's not an option I want to follow, as I love to work on my project across OS boundaries. This will be much faster than anything in WSL1, and gives you the full benefit of WSL2. So yes, for now the most important thing is: if it's at all possible, store your projects in the Linux file system in WSL2. Leaving with one recommendation in the end: Without caching, it means every "stat" operation has to make a round-trip to the host (multiple, actually, partially because of how Linux VFS works, and partially because of how 9p works). To make matter worse, to ensure the same behavior as WSL1, we don't use any caching. In WSL2, every operation has to send data to the host, exit the VM, wait for the host to perform the operation (which still involves emulating Linux behavior and the cost of Windows IO operations), send data back to the VM, trigger an interrupt in the VM, schedule the virtual processor to run, and continue executing in the VM.Įssentially, Windows files are now a "remote" file system. Windows files are now accessed across the VM boundary, however. Within the lengthy thread there was a very detailed explanation of the underlying problem, some key statements: I was not alone, in the GitHub repo of WSL I found issue 4401 which was quickly pointing to 4197. Well, the row alone does not really explain how much of a problem this might be. I searched around, if there was an issue with git under WSL2.Īnd then I got reminded about the one line of the comparison table mentioned above: Feature What was the problem? Also under Windows in a PowerShell with the Windows version of git, no performance penalty was noticable. But lo and behold: that was still very slow!ġ0 seconds (Linux git) vs ~400 ms (Windows git.exe)!Īside: hyperfine is a nice tool to benchmark CLIs and shell scripts/functions. So I turned the extension off and ran git status manually. First I didn't know what the issue was, until I discovered issue 1617 (and in another issue it is mentioned that an update to v0.45 will make it even slower, as well as a solution idea to mitigate it). Since it was my prompt every command execution in a git-managed project was slow, better yet, it took just seconds until the prompt came back. And it started with a related but independet issue in my favourite shell prompt tool starship: git_status became extremely slow in repositories of some size. I didn't even notice the performance hit across OS file systems.īut lately something was bothering me. My main reason for switching to WSL2 was much better Linux support (kernel and syscall stuff), and for a long time everything was fine. ![]() While I have experimented already with WSL 1 for some time, I switched to WSL 2 since it became generally available in Windows 10 Version 2004 (apparently it was backported to 19). The reason why it is possible, specifically if you do have Linux focused projects, is WSL (Windows Subsystem for Linux). While I still have my Linux on another hardrive, I haven't booted into it for half a year now. And to my own surprise nowadays solely on my Windows 10 installation. Here's a tip to speed up git status again.įor personal projects I work on my PC. With WSL2 filesystem performance degraded for the mount points of the Windows host.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |