I use Emacs for everything except web-browsing. Performance has never been a major concern for me. When Emacs is slow it’s almost always due to a faulty configuration. E.g., spellchecker configured to run is gigantic .csv files and similar. When native compilation dropped a while ago, Emacs became technically 2-4 times faster but I hardly noticed it. I think the perception of Emacs being slow is 90% due to the Spacemacs distro. But Doom or hand-written configs should be fine.
I used to use Emacs (for 15+ years) with a handcrafted config. It didn't feel slow because of spacemacs, which didn't even exist when I started using it. It felt slow because anything that should have been async (pushing to git, asking the LSP server to do something, you named it: spell checking, etc.) would hang up the whole UI.
There is no need to hang UI while communicating with external processes. There can be both sync and async interfaces (you don't even need threads, though they could be handy sometimes).
I use magit everyday and can't tell whether it sync or async (meaning no performance issues).
jupyter-python code blocks are definitely async (I can type in the same buffer while they are calculating something).
There is no issue with tailing logs in one vterm buffer and doing whatever in another.
Some operations are slow e.g., generating daily agenda from multi year org files (though it is not slow enough that I've bothered to do anything about it).
I wish I could do the same thing. I am really happiest using Emacs for Common Lisp, markdown, Scheme, and Haskell; and I am a fan of the very old Emacs Python support.
My problem is that I am a little obsessive about keeping all my JetBrain IDEs, LispWorks, and VSCode all set up with useful plugins. As you might imagine, I also use them.
However, I think my work flow would be better just using one tool. I like to play around with dev tools and configurations too much. I am 71 years old, I should know better :-)
I might be less than half that age, but I've given up on listening to complaints about spending time making the editor nice. I don't have any super-big configs but what I do have is careful and precise and ass a result Emacs (spacemacs) feels as much at home to me as sitting on my couch. Furthermore I enjoy tweaking my workspace. If you spend all day at it you'll never get any work done, but if you don't spend any time at it you'll miss the active enjoyment of tweaking and the passive enjoyment of having a nicer workspace.
I'll not mention all the time people gripe at me about how hard it is to learn vim commands while I save so much time on large repetitive edits that I've made back my (enjoyable) investment years ago.
My emacs config is about a hundred lines and I'm not using anything unusual at all and it's slow as shit compared to other editors. Like you said this isn't a major concern for me most of the time but I won't pretend it isn't there.
Nothing is slow with my config I don't think, it's just some font and keybind changes. I actually just checked and it's 38 lines, way less than the 100 I had guessed.
Emacs is slow. Even with native compilation. Even with the default or a minimal config. Opening files or switching buffers, imenu, isearch, etc especially in files of a few thousand lines or more, have a noticeable UI grogginess to them.
It's probably only dozens or maybe hundreds of milliseconds but it's very clearly there and always has been on every system I've used emacs on for nearly 20 years now. I do not understand emacs people who claim it isn't, or try to make it a "you're using it wrong" matter based around my config. Your config can certainly make it much worse, but you can't config it out of emacs it is part of the software.
Vim definitely starts up faster. But to make it more comparable, do you consider “emacs -nw -Q” slow too? What do you get for “time emacs -nw -Q -eval '(kill-emacs)'”?
Yes it is relative, I probably should have been more clear about that.
I am basing this entirely off of how it feels to use the tool, rather than measured timings, because I am a person who feels and not a clock that measures.
I also don't care all that much! Emacs is slow and also still the best tool for many of my uses. If it's unbearably slow for a given task I just use something else for that.
I'm not an emacs user, but it's interesting to look at the sort of changes going into a program that was originally written in 1981 (Gosling Emacs, the basis for Stallman's Emacs).
There's not many other programs that are in a similar place of very old + still in widespread use + still seeing regular feature development.
The impacts of what sort of design decisions linger on, and for how long? What change is born out of the program itself vs. having to adapt to changes in the environment? What's more likely to result in defect counts going up again? All sorts of interesting data points re lifecycle ...
1985, not 1976, though. GNU Emacs is just one of the many emacsen and doesn't share code with previous versions.
That said, it's interesting how for example original keybindings from 1976 still survive, despite being effectively a result of a quick email poll and scavenging of people's dotfiles.
Apparently it's 1981 - RMS started with the codebase of Gosling Emacs, but then quickly rewrote most of it when he replaced the Lisp implementation. Still, the blank-file moment was apparently with Gosling.
Gosling is famous for (well, not really) something called Mock Lisp: an evaluation language that worked over text that contains parentheses, evaluating the literal character-level representation. This was used in an Emacs-like editor Gosling wrote. It must be that one.
I'm guessing Stallman would have been replacing Mock Lisp with a real Lisp.
EDIT: well, doh, the Wikipedia page on GNU Emacs (which I have never visited until now, since I don't use Emacs) confirms that:
"GNU Emacs was initially based on Gosling Emacs, but Stallman's replacement of its Mocklisp interpreter with a true Lisp interpreter required that nearly all of its code be rewritten."
The existence of this relationship explains why there is a MockLisp article in the Wikipedia at all.
One recent change I cannot value high enough is optimizations which went into dealing with long lines. If you remember Emacs as being unusable as an editor for long lines, this is no more. I don't know if this went into 28.2 as I am happily using 29.0.50
Are we talking about real optimizations? I remember some years ago (with v27.1?) there were some solution for long lines introduced which basically came down to just deactivating certain features like fontlock, etc.
24 comments
[ 4.4 ms ] story [ 67.7 ms ] threadThe performance issues with elisp keep it from “conquering” more of the world.
I expect to wake up one morning and read on HN that they’ve finally fixed it.
Then the Ultimate Editor Construction Kit will win over another generation.
I use magit everyday and can't tell whether it sync or async (meaning no performance issues).
jupyter-python code blocks are definitely async (I can type in the same buffer while they are calculating something).
There is no issue with tailing logs in one vterm buffer and doing whatever in another.
Some operations are slow e.g., generating daily agenda from multi year org files (though it is not slow enough that I've bothered to do anything about it).
My problem is that I am a little obsessive about keeping all my JetBrain IDEs, LispWorks, and VSCode all set up with useful plugins. As you might imagine, I also use them.
However, I think my work flow would be better just using one tool. I like to play around with dev tools and configurations too much. I am 71 years old, I should know better :-)
I'll not mention all the time people gripe at me about how hard it is to learn vim commands while I save so much time on large repetitive edits that I've made back my (enjoyable) investment years ago.
Emacs is slow. Even with native compilation. Even with the default or a minimal config. Opening files or switching buffers, imenu, isearch, etc especially in files of a few thousand lines or more, have a noticeable UI grogginess to them.
It's probably only dozens or maybe hundreds of milliseconds but it's very clearly there and always has been on every system I've used emacs on for nearly 20 years now. I do not understand emacs people who claim it isn't, or try to make it a "you're using it wrong" matter based around my config. Your config can certainly make it much worse, but you can't config it out of emacs it is part of the software.
Vim definitely starts up faster. But to make it more comparable, do you consider “emacs -nw -Q” slow too? What do you get for “time emacs -nw -Q -eval '(kill-emacs)'”?
I am basing this entirely off of how it feels to use the tool, rather than measured timings, because I am a person who feels and not a clock that measures.
I also don't care all that much! Emacs is slow and also still the best tool for many of my uses. If it's unbearably slow for a given task I just use something else for that.
There's not many other programs that are in a similar place of very old + still in widespread use + still seeing regular feature development.
The impacts of what sort of design decisions linger on, and for how long? What change is born out of the program itself vs. having to adapt to changes in the environment? What's more likely to result in defect counts going up again? All sorts of interesting data points re lifecycle ...
That said, it's interesting how for example original keybindings from 1976 still survive, despite being effectively a result of a quick email poll and scavenging of people's dotfiles.
I'm guessing Stallman would have been replacing Mock Lisp with a real Lisp.
EDIT: well, doh, the Wikipedia page on GNU Emacs (which I have never visited until now, since I don't use Emacs) confirms that:
"GNU Emacs was initially based on Gosling Emacs, but Stallman's replacement of its Mocklisp interpreter with a true Lisp interpreter required that nearly all of its code be rewritten."
The existence of this relationship explains why there is a MockLisp article in the Wikipedia at all.
Yes. The new fixes don't work by turning off features like so-long-mode does. And they remove the long lines penalty almost completely.