Is wsl + Linux filesystem the only way to get decent perf on windows?

Hello everyone! I am really struggling to get good performances on windows with emacs... As far as I understand, windows sub-process and file system is working against emacs way of doing things. Therefore I've read multiple times that switching to WSL makes emacs much more performant. Also using a VM with Unix might help. I've tried that and basically have seen 0 improvement, especially with LSP and maggit. I've built emacs from source to be sure that native comp, etc, is enabled. Using only the Linux file system (not using /c/...) made emacs a little better but still far from my Linux experience with it :( my config works really well on Linux, so I don't think it is problematic? I am using emacs for very different purposes such as: unity c#, c++ dev (sometimes with VS), .Net, org mode, org roam, trump edit, etc... Which makes it hard to live only in the wsl Linux file system as far as I've been able to test (a pain with unity, a pain with VS, a pain with / and \, a pain with crlf and lf, etc...) Does anyone have a good way to have a performant emacs on windows please? Does the native window switch on v29 improves anything? Emacs is such a good piece of software, it makes me really sad that after battling for months to try to solve the problem, I find myself on the verge to switch editor again because I cannot ditch windows... EDIT: Common consensus seems to be to live as much as possible in WSL filesystem and share folder or have two git repositories (one win32 / one wsl). There is not much to do on emacs side, windows will probably not work that great for a long time as the core of emacs is not fit for it :( I will try again every solution proposed and come back with the one that work for me or the new editor/config I've switched to (hopefully the former!) Thank you all

[deleted]

[deleted]

Don't know WSL, but I've been using MSYS2 for years: [https://www.msys2.org/](https://www.msys2.org/) You will need to install the appropriate graphical emacs (there is also an in-console emacs, but that's probably not what you want). I'm at the point where compiling my own emacs with appropriate switches is preferred, but the pre-compiled versions are pretty good.

Right now I am using emacs 29 compiled with msys2 mingw64 libs, native compilation and native window enabled. But it should not change anything to performances on windows right? At least in my case I don't see any differences between directly downloaded windows binaries and my msys2 compiled emacs: performances are not great when accessing files/magit and spawning sub processes :( do you do anything special inside msys2 by any means? I am launching directly the runemacs.exe as deamon in the task manager at the start of windows, not launching it through msys2 CMD line. Haven't tried to do the same thing with cygwin though, might give it a try as a last thing to test!

It's hard to give you advice without understanding what actions are slow and why. WSL2 is a lightweight Linux VM so you won't get much more performance from a dedicated VM. You could try figuring out the bottlenecks and work around them, but that would require investigating what the bottlenecks are.

I've noticed great difference in win10 gui emacs' speed between different processors, I guess that's your solution on this os.

> windows binaries and my msys2 compiled emacs: performances are not great when accessing files/magit and spawning sub processes Both of those are generally slow in Windows if I recall correctly, with git in *general* having issues due to various ways in which it doesn't fit in the Windows performance paradigms (Windows also underperforms on hardware is that capable of much more in general too). So there's very little Emacs-wise that'll fix that.

I don't have a full profile available now, I could try to generate one when I come back home, best would be one on Linux and one on windows I guess? Do you have a particular command to do so please? Or should I do M-x profiler-start /stop/report? The two most obvious things are magit interactions and lsp (using lsp-mode with omnisharp or clangd for instance) being slow. Lsp is particularly slow when trying to compute and show completion for instance. On Unix I can see a noticeable speed up with the same config. I think wsl is still better than native windows if using only the wsl file system, but as it is particularly hard for me to do so I was wondering if another solution exists?

Do you mean physical hardware processor like amd/Intel ? Changing my proc is a bit of an overkill haha Maybe you meant to compile emacs specifically with the right -arch= ? GCC is generally not that bad at choosing the right hardware as far as I know

Yes exactly it is very windows related and emacs made some choices based on Unix paradigms, that is why Wsl is advised to circumvent those windows problems. But I am having trouble to interop smoothly and correctly between windows and wsl with emacs/git and unity for instance (clipboard, path, crlf, etc...) I guess we are kinda stuck with bad performances on windows which is very unfortunate as I really wish I could use emacs to its full potential even on windows. The thing is I don't even know if there is anything to do as an emacs contributor to change the situation? Windows is probably too little of the user base to justify such a huge time on this problem unfortunately.

> The thing is I don't even know if there is anything to do as an emacs contributor to change the situation? Without know much about the interop issues, I can't really say. Possibly some tools can be used that would make those things faster or more reliable & they could be optionally or opportunistically used in Emacs builds. I know the line-return stuff is already built-in behind a few options since a while. > Windows is probably too little of the user base to justify such a huge time on this problem unfortunately. Basically Emacs users stuck at work. That's your main userbase in this case.

The first :D, while windows have become substantially leaner (from 7 and on) it's still not compared to a lean linux desktop. Apart from that emacs is built with Unix in mind, wsl2 doesn't do cross filesystems that fast, wsl is slow in any other way, yadda yadda, newer hardware problem solved! The difference I'm talking about is between an i5 laptop I bought used in 2015 (i5 4200 or smt, if you want to look up the year, probably 2014) and a 2017 i7 ms surface pro I bought on a sale recently. My eyes popped on emacs first -proper- run (agenda and all)

> As far as I understand, windows sub-process and file system is working against emacs way of doing things. This is my understanding too, and it aligns with my personal experience. > Using only the Linux file system (not using /c/...) made emacs a little better but still far from my Linux experience with it You're talking about using emacs and working only within WSL2? This should be quite snappy, at least it is for me. > Does anyone have a good way to have a performant emacs on windows please? Does the native window switch on v29 improves anything? Native compilation helped a bit, but my main problem was NTFS which isn't tuned for opening lots of small files, which is the standard design philosophy on *nix. > Which makes it hard to live only in the wsl Linux file system as far as I've been able to test I've been juggling two different ways here. One is to let the windows tools work against the WSL drive (\\wsl$), and the other is to have the same git repo in both Windows and WSL, but add a remote against each other so I can pull and push between them. > Emacs is such a good piece of software, it makes me really sad that after battling for months to try to solve the problem, I find myself on the verge to switch editor again because I cannot ditch windows... I find the WSL2 install acceptable, but it takes some work and isn't a seemless experience -- but better than ditching emacs ;) Remember to install wslu on the WSL distro.

To be honest the interop part has almost nothing to do with emacs and more with win32/wsl, it is linked to the fact that we try to use Unix software on windows anyway :( opening/editing files both on wsl and win32 is not a good experience at all... the best solution would be a performant win32 emacs! Maybe in the future we will have snappy out of the box emacs on both OS! \o/

The WSL experience seems to be fine when living only in WSL land, but for Unity dev for instance I don't think it is feasible? I've run in all kind of problems when trying to open unity project from wsl and the opposite... Don't know if someone has done the experiment for a long time to edit in WSL and build/run/debug in win32 unity for instance?

You might not be able to live entirely in WSL, at least I'm not. Could you use the same techniques I'm using with duplicate repos and using remotes to sync between when needed? Or maybe the windows tools works fine against data in WSL? Or maybe it's possible to set up some rsync to sync or similar between the \\wsl and windows folder?

I'm sorry but I've not profiled emacs too much. It is true that magit is very slow on windows and that libgit2 implementation would help with that immensely (right now it's spawning bunch of processes AFAIK). I would not expect an improvement in such a case and could only suggest workarounds, such as sharing drive between Linux and Windows machines to modify files on Linux while working on Windows. If you would benefit from that you can post on an issue on magit github to increase the visibility of this issue.

It'd most probably be necessary to properly profile the whole thing to see just what is being slow. If the issue is Windows using shitty filesystems (that should be possible to deduce even without kernel-level profiling available), there's not much to be done other than avoiding any use of those filesystems.

>do you do anything special inside msys2 by any means? runemacs.exe and emacs.exe from my compilation differ, but I couldn't tell you what the difference is. Just to check the obvious: Have you run speed checks on your Disk? Memory? CPU? Things like crystaldiskmark and friends.

Last I was stuck on windows virtualbox with linux without working in shared folder was fastest. Then again your first inclination when stuck on Windows might not be to get out as soon as possible into a linux vm.

I wonder if anyone here has had success with multiple frames with wsl/g. Switching frames has not worked across multiple installations.

I just landed a job where using an assigned Windows machine is \_mandatory\_. I'll be watching this thread :/

Seems like a solution I have not yet tested. I will try the VM with shared folder but I expect it to be kinda the same performances as with WSL2? Well, when stuck on windows, my first inclination IS to get out as soon as possible haha

I have been able to have multiple frames with vcxserver and wsl if I recall correctly, what part is not working for you?

I see, I will test again all the solutions in the thread and will open an issue for magit if I see fit, thank you!

Seems like a reasonable solution but I am not sure it would work for my workflow, anyway I will think about it and test this. I will try to live as much as possible in WSL and go on windows only when needed by way of sync or shared folder

Syncthing works pretty good, so I'll try to change to using that. Duplicates all HDD space, but it's worth it if I can use Emacs and GNU/Linux tools.

Good luck!

I’m using wslg. The command other-frame simply doesn’t work. I can create and close other frames, but moving to other frames is a no go. It may be a limitation within wslg but I’m not privy enough to comment where this breaks. I believe it has to do with calling the focus related apis specifically but the code at this layer isn’t immediately clear to me.

I specified without a shared folder. As in I basically do everything in the linux VM and only use the shared folder when forced to use a windows only application or something.

My bad I misread your post, got it!