The big things are indeed being outsourced to separate processes. LSP handles a lot, I also see some attempts at moving syntax highlighting to tree-sitter[0]. But all such work means a good chunk of code is running inside a foreign process, whose behavior cannot be easily inspected or modified at runtime.

But there are a lot of various smaller things in Emacs and elisp module ecosystem that would benefit from being able to run off the main thread. Emacs performance is fighting death by a thousand cuts, with almost everything being tied to the main thread (despite async features being used to pretend it's not).

--

[0] - https://tree-sitter.github.io/tree-sitter/

The inspection and modification is a strong point that I should have considered.

I stopped using Gnus because its elisp freezes Emacs (I now use mu4e, which has a separate process).

I would guess Eww would have a similar issue, although I've never been able to get it to work (I use emacs-w3m, which has a separate process).

I've found some programming modes to be very slow and prone to freezing; most noticably Scala using Metals (which uses lsp).

Do you know what makes it freeze? My gut would be that they did not set a buffer with a sentinel, such that even with threading, they would have still don't a blocking call there.

That said, valid points. I am curious to benchmark parts of emacs now. (I turned off most programming features, since most of my code is remote and the network at home kills me.)

> Do you know what makes it freeze?

For Gnus it was using the built-in fetchers like nnrss, which would block the Emacs process until downloads finished. Using a cron job to fetch RSS feeds avoided this, but it would still take a while to check for updates even from local files. This was around 2012, so Gnus might have improved since.

FYI my current setup is described at http://chriswarbo.net/blog/2017-01-14-rss_to_maildir.html