Hacker News Reader

This deviates outrageously from my experience. The figures you’re giving are so extremely anomalous that there must be some simple explanation.

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.

WSL1 editing a local file. Start WSL, type 'emacs -nw file'

I have no idea what 'conhost' is so I can't comment.

conhost is Windows’ console host. If you’re running it in Command Prompt or equivalent, you’re running it in conhost.

-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.)

Other than an interesting anecdote, this doesn't say much at all. Show us a bug report instead, and more details.

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.

When I moved over from WSL to WSL2, WSL2 was extremely slow. I quickly realized my mistake. On WSL2 IO on the Windows filesystem is actually extremely slow. I moved my projects to the WSL2 filesystem and run my IDE on WSL2 with VcXsrv and I love it.

In WSL 1, Linux accessing Windows files is slow, and Linux accessing Linux files is extremely slow.

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.)

Are you using WSL2 or 1? 1 has had problems with speed due to windows antivirus. WSL2 is virtualized and much faster.

Windows 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.

TBH the "Windows" way would be to use the Microsoft Store. Chocolatey/scoop is just a Linux way of installing software, ported to Windows. Even conemu is a Linux way of managing terminals; the Windows way would be to use GUI all the way.

It certainly breaks with Windows tradition, but you're still not writing in BASH. I would call it "New Windows". Windows tech that is written for Windows but is acknowledging that there may be a better way to do things. Regardless, they're all making win32 kernel calls, and no need for an emulation/virtualization. They were, at least, written for Windows.

You can use WinGet which is official as well

https://github.com/microsoft/winget-cli

I use WSL2 as my daily driver on a laptop. I find CPU performance to be very good if not quite equal to the native Linux setup I had previously. I don't run IO heavy tasks daily, so no comment on that. I do develop things that require a much newer Linux kernel (eBPF/XDP) so I also have a couple more VMs on Hyper-V, and finally remote machines with proper NICs (that I wouldn't really be able to have on my laptop anyway) - yet still, the whole setup feels very convenient and snappy.

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 hardly consider typing text as "a heavy IO task". I max out at 40 WPM

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.

It's disappointing that there are a bunch of questions here about the poster's setup and he hasn't come back to answer them. Makes it feel like they have no real interest in actually engaging and finding answers.

Relax.

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.

No, but it’s a very nice tool to have. I work primarily in windows but needed to run some tools in Linux. I just fired up my WSL terminal, ran my commands, and got on with my life.

It is nice and useful if you just want to do a "hit and run", like grep a file.

I'm just suggesting that it is not a tool for larger tasks. Install VirtualBox, which works well.

I can't bring myself to leave a bug alone. So my "debugging saga" continues. I've noticed 3 things.

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.

Well, of course. WSL is not Linux. It is Windows.

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.

Running anything in VM is always not bare metal. Just run Linux on your hardware. The only use case for WSL is when someone forces Windows on you (like corp IT?) and you don't have a choice.

Word

I don't use it (LibreOffice if anything). You can also try Wine if you are stuck using it.

I've had similar experiences. The name of the game for me is convenience when I can't use my linux machine for a simple task, for that WSL does quite well, and that's about it.

I would encourage you to at least consider that your issue is a bug or perhaps a wsl version issue rather than throw your hands up and point to a conclusion from years ago that windows is a pretty toy and just not up to the task.

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.

I normally install VirtualBox. It runs just fine and has not ever had a lag problem. I didn't install VirtualBox, opting to use WSL instead (Ubuntu).

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.

can confirm. i've also found really odd bottlenecks with hyperv virtual switches (even with "for workstation" sku with a 3970x). i now have a proxmox ve machine for all local non-windows needs on an i7 nuc.

WSL 1 is an implementation of the sys call interface of the Linux kernel.

WSL Isn't Linux