WSL Isn't Linux
But I'm a programmer and I make heavy use of my machines. I expect performance.
For example, I'm creating a column of numbers. In emacs, I wrote a keyboard macro to update the 10s column (i.e. 10 0s, then 10 1s, up to 10 9s) because who needs to type 100 numbers and 200 arrow keys?
In Linux this keyboard macro updates 100 lines and runs as fast as a single keystroke.
In WSL it takes MINUTES to run. And when it completes, the next keystroke takes minutes. In frustration I started doing the same task by hand. It worked fine until I had about 1000 lines at which point I could watch the screen updates lag so badly I had to wait for the machine. The performance continued to degrade. Apparently they are updating the whole files worth of screen on every keystroke. At 2000 lines I could go for coffee while it updated my last 10 keystrokes.
Normally I would consider this a bug. However over the years I've come to the conclusion that Windows is a pretty toy. It works wonderfully "in the small". But it isn't useful for significant programmer workloads (like typing :-) ).
If you think you can use it anything significant, like program development, think again.
Your mileage may vary (but I suspect your odometer will be lagged :-) )
27 comments
[ 1.7 ms ] story [ 88.4 ms ] threadWindows is plenty fast these days, but if you want it to be fast you have to do things the windows way -- conemu, powershell, chocolatey, etc. You can and should also use emacs and vim natively on windows (not via WSL). I use gvim on windows and it works well with these Microsoft tools. I can even send text from vim to conemu as a means of using a REPL. I just set up a python shell or clojure shell on conemu and I'm good to go.
https://github.com/microsoft/winget-cli
I'm just suggesting that it is not a tool for larger tasks. Install VirtualBox, which works well.
I've been using Linux full-time for 17 years, moved to WSL2, I've not noticed any particular problem. In fact I'm more productive than ever and my beefy machine feels even faster than it ever did on Linux. There are downsides, sure, but nothing to justify any ridiculous slowdown you have experienced.
Unless you think mine is not a significant programmer workload.
In WSL 2, Linux accessing Windows files is very slow, and Linux accessing Linux files is fast.
A couple of years back Fastmail’s webmail build process did a lot of theoretically unnecessary process spawning and file rereading (spawning Node.js several thousand times). I don’t have the exact figures on hand, but in WSL 1 with the files on C:, a full build would take about half an hour (files in WSL was not even worth considering, it took many hours). Under WSL 2 on C:, that full build would take an hour and a half. Under WSL with files under Linux, it was down to just a few minutes (partly because of faster I/O, partly because of faster process spawning). As I say, I don’t have the exact figures on hand, but that’s my recollection of the ballparks.
Like you, I steadily shifted just about all my stuff to the Linux side and reaped the benefits. After a while I even uninstalled Windows gVim altogether as I was always using Linux Vim in the terminal. (I start things in VcXsrv occasionally, but not often.)
I wouldn't run a production server on WSL, that sounds like madness. It is, however, a great development environment for me, where I have almost everything I needed from the Linux side, along with allowing my laptop to do 8 hours on battery on Windows as opposed to 3 on Linux, sleep working properly, wifi not needing an occasional reboot to start working after wakeup, etc.
So my anecdote vs your anecdote: it works (great) for me.
I'm not running a production server (or anything else compute-intensive). I agree that Windows does the "toy" things better than Linux, such as web browsing, sleep handling, sound management, etc. These are "appliance" level tasks where Windows is definitely better.
That said, I wouldn't even consider doing a full system build (takes about 3 hours on my fastest machine) on WSL. All I'm trying to do is enter 2800 numbered lines of text. The Windows machine was more portable so I chose to move it to the problem rather than move the problem to my office.
Now I'm continuing on WSL and trying to understand the faulting behavior.
Linux has a massive head start when it comes to performance optimization--especially since most Linux installations don't come with the performance penalty of also running Windows.
I'm sure the types of bugs you wrote about will be ironed out soon enough.
Are you running WSL 1 or WSL 2? Is this emacs in a terminal, or GUI emacs via VcXsrv or similar? Where is the file, on the Windows side or the Linux side? How is emacs configured for, I dunno, swap files or whatever its equivalent is (I’m a Vim man)?
My first guess is that you’re using WSL 1 and accessing Linux files, and that emacs is doing synchronous flushing writes of some kind of swap file on the same file system after every tiny thing. If this is correct, I scream in horror at the magnitude of the wrongness of what emacs must be doing.
My second guess is that you’re running emacs in Windows’ conhost, and it’s emitting vast amounts of data to the terminal for whatever reason. conhost is really slow, though it’s getting a bit better.
If neither of these is correct, I’d be interested to know what is going on. Profiling may well make the answer obvious, though if you’re on WSL 1 I’m not sure if the standard profiling tools will work. If you’re on WSL 1, upgrade to WSL 2, it’s superior and faster in all regards except performance of accessing Windows files, which is way slower (but accessing Linux files is enormously faster). I’m convinced that there will be a simple explanation.
I have no idea what 'conhost' is so I can't comment.
-nw means that you are running it inside a terminal emulator, which will be conhost unless you know you’re using a different terminal like the new Windows Terminal or Alacritty. This is very likely to be the problem—emacs is probably emitting large amounts of text (megabytes) to the terminal emulator with inefficient screen updates, and conhost is agonisingly slow. To be clear, I expect that Emacs is still substantially at fault here, because it sounds like it’s updating the screen in an extremely inefficient way that just happens to work well enough on Linux’s faster terminal emulators.
Switching to a different terminal emulator that uses the new ConPTY interface, such as Alacritty or Windows Terminal, should speed things up a lot. But it’ll still be a good deal slower than the likes of xterm and urxvt and Alacritty on non-Windows platforms because ConPTY is still a substantial performance bottleneck.
Various actions that are likely to help:
• Upgrade to WSL 2.
• Switch to a ConPTY-based terminal emulator like Windows Terminal or Alacritty.
• Run Emacs in GUI mode via VcXsrv. (Sadly this isn’t quite as easy in WSL 2 because your $DISPLAY needs to include the IP address and VcXsrv needs to be told the IP address. In WSL 1, `DISPLAY=:0` would do it.)
I limit myself to 1 visit per website per day because I have to get things done. On HN I limit myself to the first 1000 posts so I have a breakpoint.
Clearly I've returned within 8 hours, violating my own rules (but it IS sunday :-) )
That said, I've been trying to understand the nature of the problem by continuing to use WSL (against my better judgement). I have more to complain about.
I'm not much of a Windows fan but I do understand the usefulness and convenience of having a linux dev environment when forced to use windows for one reason or another.
Normally such a lag is due to paging. But paging lag has a "blocky" kind of update, long lag then fast update. This problem seems to be more about event handling (more about that in another reply) as it occurs on every character.
First, if you use the arrow keys to move around, the cursor lags and even disappears. This is really not useful when trying to reach a position in an editor.
Second, emacs split buffers (C-X 3 splits the buffer into 2 side-by-side windows) has a problem. The screen refresh sometimes trashes the display. It can be recovered with C-L, of course, so the data isn't damaged but it is annoying. The cursor control is even worse in this configuration. Sometimes the cursor leaves the current buffer and ends up somewhere else on the screen so it appears you are typing in a random screen location. C-L recovers this and you see the data in the correct place.
Third, rather than using a keyboard macro I used "galloping fingers". That is I repeatedly hit
1 down left... 2 down left... 3 down left, in overwrite mode to create columns of numbers.
I've been doing this for years (I've been programming for 50 years). At this point my fingers are, like a drummer, highly reliable. I get a rhythm going and rarely fail... except that on WSL some of the keystrokes get lost so I end up with missing numbers or in the wrong column. It happens about every 50 or so numbers. I notice that it seems to happen when emacs autosaves. So somehow the autosave interruption is losing keystrokes.
I find it hard to believe that keystrokes get lost but that appears to be at least one of the problems. It seems also to be related to "injected keystrokes" in a keyboard macro. Cursor control is also badly broken. This might be related since cursor movement is keyboard driven.
I don't have Windows source code so I'm only guessing.