Which is the most performant WSL2 setup to work with PHPStorm/WebStorm?
So recently I've discovered that there are 2 new options to work on my WSL 2 projects.
Currently, I'm using PHPStorm on a Windows 11 machine and work on a WSL directory. It also uses all the tools (node, git, etc.) on the WSL machine, but from within the IDE running on Windows 11. This works quite well although I wonder if I could get better performance using the following alternative options:
New option 1: Install PHPStorm directly on the WSL 2 Ubuntu and use it as graphical application. That works! It only looks a bit ugly, because there is this thick frame and no "real" fullscreen mode. It's also a bit annoying that it can only open the Ubuntu Browser (Firefox, ok nice, but I would need to configure everything twice for decent development) and not the one I run on Windows.
New option 2: Connect to a PHPStorm instance running on the WSL, like a "remote control", via "Remote Development -> Connect to WSL"
I wonder if Option 1 or Option 2 offers me a better IDE performance (like indexing, code completion, refactoring, search everywhere, etc.) than running the complete IDE on Windows 11.
Does anybody have some longer experiences working with one of the two other options?
Please sign in to leave a comment.
Running apps in a VM always comes with an overhead, so PhpStorm run in WSL will be heavier than PhpStorm run on the host.
So, when it comes to performance, option 2 is significantly better.
People mostly use option 1 for better software compatibility - having local VM paths (as opposed to \\wsl$ paths) in your IDE is sometimes a game changer.
So I've done a few methods. I started off running PHPStorm in WSL and using an XServer. That didn't do bad, and overcame the symlink problems PHPStorm has with WSL.
I then switched back to running PHPStorm on Windows. This too isn't bad, except the problem mentioned above.
Now I'm back to running PHPStorm in WSL using WSLG. The ugly frame problem is fixed, but it appears to be in a prerelease (you can wsl --upgrade --pre-release to get it). I've only started using this method this week and so far it works good.
As far as launching browsers from PHPStorm in WSL, you can launch a Windows installed browser by setting the path to the executable in Windows. Just change C: (or whatever drive) to /mnt/c and be sure to change all the \ to / and add the .exe. Here's mine (FYI - I use Chrome Canary for all my dev work)
/mnt/c/Users/jamie/AppData/Local/Google/Chrome SxS/Application/chrome.exe
What I like about using WSLg is that I can keep separate work from my own stuff. I've got two installs of WSL and run PHPStorm in each. One is setup for work, including all my work github and other credentials. Then in my personal one, I use my own Github, Gitlab, etc. Hopefully it keeps working this way, because I really like it a lot better.
Thanks for your insights!
Compatibility for me isn't really a problem right now, the IDE works very well directly under windows, also when working on a WSL project.
I just wonder where the bottleneck is. Let's say the whole project gets indexed. Does it take longer when the IDE is run on windows and it is accessing the files on the WSL via \\wsl$\... or does it take longer when I'm connected to a PHPStorm Instance on the WSL via "remote development"? In the second case, I still use the Windows IDE, but as a "remote control" for a PHPStorm Instance running on the WSL like a server. That also means, that those instances have to be connected somehow. And I wonder is the connection between those two could be a bottleneck or if it doesn't matter at all. Because when you're typing, the text gets sent to the PHPStorm on WSL, there it creates some code completion hints and other suggestions that will get sent back to me and displayed.
Also, Memory management is also an interesting issue. Does a PHPStorm instance running on WSL (with no gui, just as a "server" for the instance running on windows) consume more or less memory? Currently I have allocaed 4GB for PHPStorm on windows. I have 64GB in total, I could easily crank it up. But then, the vmmem also can grow quite big.
Here, the performance overhead will be fighting with the poor
\\wsl$access to the WSL file system.Normally, the native Linux file system would be faster than access through the UNC path, and also having an antivirus running on the host might make it severely worse.
On the other hand, as you noticed with the Vmmem process, the performance overhead is a thing and it is very noticeable, especially when it comes to memory usage.
This network communication is the least severe problem you get when running PhpStorm in WSL, as everything's local.
PHPStorm is smart enough that when running the normal windows version but accessing files over \\wsl$, instead there is a little ‘file notifier helper’ installed on it. I believe it uses this for most file access, and to support getting updates when files change.
So I don't know if ‘the slow \\wsl$ access' is still an issue that way. Also, \\wsl$ file access got quite a lot faster in the Windows11 WSL modules (Which are now available for Windows10 as well if you install through the store).
Personally, when using the client/host method (like VSCode uses) would seem fine. But there is a big ‘yeah but' with IntelliJ / PHPStorm.
Running my WSL2 instance (which starts php + webserver + database and all that) takes just less than 1gb of ram.
Running PHPStorm natively in Windows then takes 3.5gb of RAM when opening a project. (!!).
But, when running the client/host method, my WSL2 VM memory usage jumps up to over 7GB, and I still get the Jetbrains Client that uses 1GB and some other local Java tools launched.
Memory usage seems broken. Also, with the client/host model, the CPU usage in the host (so in the WSL2 VM) never goes down to really nothing. It seems it's _ALWAYS_ busy doing something, even when not indexing or not typing. Just having Client / WSL-phpstorm open that sends my laptop fans going crazy.
Native seems the way to go for performance at this moment. But PHPStorm is still a big heavy beast. Even when disabling every plugin that's not in use or I have no interest in, it's slow to start, takes up quite a bit of resources, … This seems to be double as big a problem when running it remotely.
Built in support for Linux GUI programs is now a thing, even for Windows10, so maybe that is still a better way to go (like the WSLg things above). I might try that.