I’m not convinced emacs performance is that bad. It’s pretty highly optimised for typing at a normal rate though I agree the data structures aren’t great for more graphical things (lots of properties, random access inserts, even just long lines). But then the way to improve this is to improve the data structures rather than replacing emacs lisp.
Emacs performs better than many other applications at important objective measures, eg the time between pressing a key and the character showing up on screen. You might expect vim to be good at this but many terminal emulators are optimised for throughput rather than latency and are slower than gui emacs.
Certainly legacy is a problem but I worry that replacing eg font-lock with something with better performance properties (does this actually do that?) means throwing out the baby with the bath water as so many modes depend on these things.
Typically the reason that emacs becomes slow is due to an overload of features or bad asymptotics. Examples:
- global-auto-revert-mode plus lots of buffers plus some in a slow file system like nfs or maybe lots of open fired buffers
- some mode using a configured alist that works fine for small lists but really sucks for big ones (ie perf is linear in size of config, but often this comes hand in hand with trying to process big inputs so it can be worse.) I think this happened with spacemacs and which-key-mode for example
- flyspell + flycheck + build running in background + some autocompletion server. Even a powerful computer can be slowed down by this. Some of these are likely to slowly improve over time as they become more synchronous. Others are problems you’re likely to have with any editor (a nice emacs thing was that it was easy for me to add some advice to pin my build to not use all my cpu. It can be really hard to poke around in other plugin systems to do that sort of thing without a config option for it)
- just piling on the nodes with something like spacemacs and not paying attention to the performance of the whole. I think doom-emacs shows a lot of promise here.
I do think there are advantages that could be made by modernising emacs’ core and improving data structures (whatever happened to remacs?)
I feel like the fundamental design of emacs is good however and I like:
Obviously you should disregard all of this though as I am very biased due to my emotional reaction to getting rid of emacs lisp which, frankly, you can pry from my cold dead hands.
————————————
Some other thoughts I had on emacs lisp as a good language for a text editor:
> I’m not convinced emacs performance is that bad.
In my experience with modern hardware - a gaming PC - Emacs is noticeably sluggish compared to most other editors in a few specific ways: particularly syntax highlighting. When is the last time you used a different editor?
remacs is dead, they don't accept merge requests. For some reason they did not find it reasonable to mention this in the README, so sometimes potential contributors arrive and do unnecessary work until someone tells them it's "stalled".
one fundamental thing I run into fairly often is Emacs horrific performance on long lines. Not really an issue for code, but looking at large JSON or text files routinely almost crashes my Emacs.
Agreed: for most of my day to day tasks, emacs is performance enough, subject to the constraints of my CPU vis a vis interpreting the underlying lisp...but I do find myself actively avoiding a long line of JSON blob, because of the reliable repeatability of emacs locking up and becoming unusable on a long line.
It’s not enough to stop me using emacs, but it is enough to make me go out of my way to avoid it (and to grumble about).
Emacs performs better than many other applications at important objective measures, eg the time between pressing a key and the character showing up on screen. You might expect vim to be good at this but many terminal emulators are optimised for throughput rather than latency and are slower than gui emacs.
Certainly legacy is a problem but I worry that replacing eg font-lock with something with better performance properties (does this actually do that?) means throwing out the baby with the bath water as so many modes depend on these things.
Typically the reason that emacs becomes slow is due to an overload of features or bad asymptotics. Examples:
- global-auto-revert-mode plus lots of buffers plus some in a slow file system like nfs or maybe lots of open fired buffers
- some mode using a configured alist that works fine for small lists but really sucks for big ones (ie perf is linear in size of config, but often this comes hand in hand with trying to process big inputs so it can be worse.) I think this happened with spacemacs and which-key-mode for example
- flyspell + flycheck + build running in background + some autocompletion server. Even a powerful computer can be slowed down by this. Some of these are likely to slowly improve over time as they become more synchronous. Others are problems you’re likely to have with any editor (a nice emacs thing was that it was easy for me to add some advice to pin my build to not use all my cpu. It can be really hard to poke around in other plugin systems to do that sort of thing without a config option for it)
- just piling on the nodes with something like spacemacs and not paying attention to the performance of the whole. I think doom-emacs shows a lot of promise here.
I do think there are advantages that could be made by modernising emacs’ core and improving data structures (whatever happened to remacs?)
I feel like the fundamental design of emacs is good however and I like:
1. keymaps and the command loop
2. Buffer-local variables, advice, dynamic scoping
3. Documentation
4. Fundamentally text-based interface
Obviously you should disregard all of this though as I am very biased due to my emotional reaction to getting rid of emacs lisp which, frankly, you can pry from my cold dead hands.
————————————
Some other thoughts I had on emacs lisp as a good language for a text editor:
1 https://news.ycombinator.com/item?id=19343908
2 https://news.ycombinator.com/item?id=22881597
3 https://news.ycombinator.com/item?id=18605001
On the “fast” measurement that actually matters: https://news.ycombinator.com/item?id=23432292