Our great sponsors
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
One possible solution is to switch to a LSP approach. You should also take a look at the garbage-collector-magic-hack package: https://github.com/emacsmirror/gcmh
Also, as others have pointed out, coding a new multithreaded emacs is too ambitious. You should browse the C source. There are more than 400,000 lines of C code there. You're not going to refactor that easily. This is not happening.
Are you running emacs-29? It has numerous speed-ups compared to emacs-28 and older versions, many of them coded by Mattias Engdegård, e.g. commit def6fa4246. I have a fresh build of emacs-29 running on Linux and a new mac with an M1 CPU, and it's stupid fast. I don't use the native-comp feature. I rarely notice any hesitation or slowness. I don't use Elpy. I do use lsp mode.
gcmh doesn't solve the blocking waits, and can lead to some weird performance issues, caveat emptor
Why don't you ask Linus? Or even better, read his motivation in his fork of microemacs (not GNU Emacs).
Async process can do that. Have you checked async library by Wiegley? You can use another emacs process as a sort of clean interpreter thread similar to javascript workers.
Indeed, at this point it's just better to contribute to Lem.