5 ms·

Emacs Lisp is slow. There has been a multi-decade effort to make Guile support ELisp, and using Guile to make Emacs more performant. Cross platform UI, with a

Emacs Lisp is slow. There has been a multi-decade effort to make Guile support ELisp, and using Guile to make Emacs more performant. Cross platform UI, with a faster Lisp, would allow Emacs to be even more special.

gpderetta 6y ago
the new AOT compiler seems promising though and has a good chance of actually making it into the release.
globular-toast 6y ago
Yes... but it's not that slow. In practice, emacs works at least as fast as I can think most of the time. This is the most important thing for me. It's the reason why I originally switched to git from svn (Linus also specifically mentions this as a design choice for git). In this day with electron and editors like VSCode I wouldn't call emacs particularly slow.
- gpderetta 6y ago
  I think the reason that emacs feels fine most of the time even if elisp is slow is that usually abstractions are fairly minimal.
- wiredfool 6y ago
  I’m not sure about the others, but rjsx mode is slow with moderately complicated files, and the (idr which) accompanying refactor minor mode is glacial on a mbp.
  - morelisp 6y ago
    rjsx is based on js2 which makes it unusually slow. js2 was a valiant attempt to make a major mode that uses elisp to actually parse the language. This gave it tremendous power compared to every non-Lisp major mode and most other JS editors at the time, but it has not aged especially well in modern JS support or performance. I’d try one of the LSP based approaches instead these days.
- marcosdumay 6y ago
  More important, I never have to wait emacs to fill a buffer with the text I've typed. Yes, on some modes there is a visible delay between pasting text and being able to type again, or writing some code and it telling me it's wrong. But the one kind of interaction that matters is always flawless. Many editors do not get this right.
5h 6y ago
As a non Emacs user, is the speed of Emacs Lisp a frustration in typical day to day usage?
- rusk 6y ago
  Sometimes. But, in my experience a lot of these advanced development environments can be quite hang-ey if you know what I mean. It’s quite lightweight relatively speaking so more than makes up for it.
- jsilence 6y ago
  For me as a long term Emacs user, started using it 1994ish, it is not an issue. I don't mind the occasional minor lag. In my usage it is rarely in a range where it actually makes me wait. Emacs has a certain feel to it. Hard to put the finger on, but the movement of the cursor and the scrolling, it just feels nice for me. Like a well worn favourite T-Shirt.
- monsieurbanana 6y ago
  Sometimes. Vanilla emacs is lightning fast, but it's also missing critical features for most people. If you want to use emacs as a an alternative to VSCode, or IDE in general, you'll find high quality plugins that will enable you to do so. But then you might experience slow downs. As emacs is single-threaded (people will come and tell me it's not anymore, I know, but in practice it still is) you'll feel any slow downs in those plugins. Emacs typing latency isn't great. It's a mixed bag really. It can be fast, it can be slow. It's still my favorite editor.
- jmiskovic 6y ago
  What are you using now? If VScode or Atom you won't feel any degradation. If vim or SublimeText, some things will take few extra dozens of milliseconds. You could test the Doom Emacs, which is trying to be a feature-full emacs environment optimized for speed.
  - 5h 6y ago
    I've been using Vim for a very long time now, recently adding CoC has slowed things a bit however I am quite fond of some of the features, so I might start enabling it only when I want those. I'm not looking to encouragement to change (after 20 years in Vim that ship has likely sailed for good), I was just curious if the speed of Emacs lisp was a frequent bugbear.
tikhonj 6y ago
There's some new development going on that compiles Emacs Lisp to native code with GCC and it is a real performance improvement. I've been using it on an unstable Emacs build for the past few weeks and I can feel the difference—noticeably snappier and more satisfying. It's not 100% ready for day-to-day use yet—the deferred compilation logic seems to be recompiling more often than it has to—but I've been quite happy with it so far, and it will make a substantial improvement for Emacs users once it's stable and rolled out. Hoping it can be released with Emacs 28 or 29 at the latest :).
- agumonkey 6y ago
  What's your machine specs ?
- anthk 6y ago
  Also Emacs can lock the rest of the panes while doing I/O. How could native code solve that? Guile at least could.
bjoli 6y ago
Guile Emacs will never happen. Robin's work was amazing, but at it's absolute height guile Emacs was still a slower and buggier version of regular Emacs. I am pretty certain a full guile Emacs would be better than current Emacs (guile is actually a very neat little VM with lots of cool optimisations going on), but that is not where the reality is. As a guiler I want Emacs to be guile-based, but I totally understand the Emacs POV: guile is an external dependency with unsecure maintainership.
- pmoriarty 6y ago
  Never say never. Guile Emacs was the work of one (very talented) guy. He's moved on to other things, but it's not inconceivable that another Guile fan will pick up the torch some day. If enough Guile/Emacs fans get together this might actually turn in to a viable, maintainable project... this is, after all, how Neovim started. Just some people who were unsatisfied with where Vim itself was going, and teamed up to make their alternate vision a reality -- with great success. Guile Emacs work is actually a much smaller task than Neovim, as Neovim's authors rewrote Vim from scratch, whereas Guile Emacs has a much more humble aim of simply allowing eLisp to be hosted on the Guile VM. It could still happen.
  - bjoli 6y ago
    With the direction guile has been going in lately, guile is only becoming more attractive. The problem with integrating it is that you need someone with good knowledge about guile (since the elisp implementation is pretty bad currently) but even more important: someone who know Emacs internals (not many).
slightwinder 6y ago
Multi-decade effort..wasn't that done by just 2-3 guys as an alternative attempt? Anyway, while elisp might not be the fastest language around, it's not the origin of all slowness in emacs. Crufted design is also a big culprit. The dated regex-machine is often mentioned as a big problem, making syntax highlighting especially painful.
- duckonomy 6y ago
  Some people are saying that https://github.com/ubolonton/emacs-tree-sitter https://github.com/ubolonton/emacs-tree-sitter will eventually replace the default regexp-based font-lock for syntax highlighting. I'm personally testing it out and it's been great!
- pmoriarty 6y ago
  Apparently, Emacs' display code shares the blame, and no one wants to touch it as it's written in some really hairy legacy C. Though I'm not a Rust fan, and would infinitely prefer Guile Emacs, I am kind of half-hoping Remacs succeeds so Emacs can finally put all of that legacy C behind it.
LandR 6y ago
My experience on windows is that emacs is unusably slow. Multi-second lag on type and navigating isn't acceptable. Org-mode is especially bad.
- jonrx 6y ago
  I think it's related to the fact that emacs has multiple (very) small files and short-lived processes, which does not work well/fast on Windows. For a while, I ran Xubuntu in a VM just to use emacs, because the performance on my Surface book 2 was unacceptable. I ended up going in the other direction: kept emacs, got mostly rid of windows (I have it in a VM for the odd occasion where I need to use a windows-specific program. The fact that my company is flexible on the work OS is a huge bonus for me.

gpderetta 6y ago

the new AOT compiler seems promising though and has a good chance of actually making it into the release.

globular-toast 6y ago

Yes... but it's not that slow. In practice, emacs works at least as fast as I can think most of the time. This is the most important thing for me. It's the reason why I originally switched to git from svn (Linus also specifically mentions this as a design choice for git). In this day with electron and editors like VSCode I wouldn't call emacs particularly slow.

gpderetta 6y ago
I think the reason that emacs feels fine most of the time even if elisp is slow is that usually abstractions are fairly minimal.
wiredfool 6y ago
I’m not sure about the others, but rjsx mode is slow with moderately complicated files, and the (idr which) accompanying refactor minor mode is glacial on a mbp.
- morelisp 6y ago
  rjsx is based on js2 which makes it unusually slow. js2 was a valiant attempt to make a major mode that uses elisp to actually parse the language. This gave it tremendous power compared to every non-Lisp major mode and most other JS editors at the time, but it has not aged especially well in modern JS support or performance. I’d try one of the LSP based approaches instead these days.
marcosdumay 6y ago
More important, I never have to wait emacs to fill a buffer with the text I've typed. Yes, on some modes there is a visible delay between pasting text and being able to type again, or writing some code and it telling me it's wrong. But the one kind of interaction that matters is always flawless. Many editors do not get this right.

5h 6y ago

As a non Emacs user, is the speed of Emacs Lisp a frustration in typical day to day usage?

rusk 6y ago
Sometimes. But, in my experience a lot of these advanced development environments can be quite hang-ey if you know what I mean. It’s quite lightweight relatively speaking so more than makes up for it.
jsilence 6y ago
For me as a long term Emacs user, started using it 1994ish, it is not an issue. I don't mind the occasional minor lag. In my usage it is rarely in a range where it actually makes me wait. Emacs has a certain feel to it. Hard to put the finger on, but the movement of the cursor and the scrolling, it just feels nice for me. Like a well worn favourite T-Shirt.
monsieurbanana 6y ago
Sometimes. Vanilla emacs is lightning fast, but it's also missing critical features for most people. If you want to use emacs as a an alternative to VSCode, or IDE in general, you'll find high quality plugins that will enable you to do so. But then you might experience slow downs. As emacs is single-threaded (people will come and tell me it's not anymore, I know, but in practice it still is) you'll feel any slow downs in those plugins. Emacs typing latency isn't great. It's a mixed bag really. It can be fast, it can be slow. It's still my favorite editor.
jmiskovic 6y ago
What are you using now? If VScode or Atom you won't feel any degradation. If vim or SublimeText, some things will take few extra dozens of milliseconds. You could test the Doom Emacs, which is trying to be a feature-full emacs environment optimized for speed.
- 5h 6y ago
  I've been using Vim for a very long time now, recently adding CoC has slowed things a bit however I am quite fond of some of the features, so I might start enabling it only when I want those. I'm not looking to encouragement to change (after 20 years in Vim that ship has likely sailed for good), I was just curious if the speed of Emacs lisp was a frequent bugbear.

tikhonj 6y ago

There's some new development going on that compiles Emacs Lisp to native code with GCC and it is a real performance improvement. I've been using it on an unstable Emacs build for the past few weeks and I can feel the difference—noticeably snappier and more satisfying. It's not 100% ready for day-to-day use yet—the deferred compilation logic seems to be recompiling more often than it has to—but I've been quite happy with it so far, and it will make a substantial improvement for Emacs users once it's stable and rolled out. Hoping it can be released with Emacs 28 or 29 at the latest :).

agumonkey 6y ago
What's your machine specs ?
anthk 6y ago
Also Emacs can lock the rest of the panes while doing I/O. How could native code solve that? Guile at least could.

bjoli 6y ago

Guile Emacs will never happen. Robin's work was amazing, but at it's absolute height guile Emacs was still a slower and buggier version of regular Emacs. I am pretty certain a full guile Emacs would be better than current Emacs (guile is actually a very neat little VM with lots of cool optimisations going on), but that is not where the reality is. As a guiler I want Emacs to be guile-based, but I totally understand the Emacs POV: guile is an external dependency with unsecure maintainership.

pmoriarty 6y ago
Never say never. Guile Emacs was the work of one (very talented) guy. He's moved on to other things, but it's not inconceivable that another Guile fan will pick up the torch some day. If enough Guile/Emacs fans get together this might actually turn in to a viable, maintainable project... this is, after all, how Neovim started. Just some people who were unsatisfied with where Vim itself was going, and teamed up to make their alternate vision a reality -- with great success. Guile Emacs work is actually a much smaller task than Neovim, as Neovim's authors rewrote Vim from scratch, whereas Guile Emacs has a much more humble aim of simply allowing eLisp to be hosted on the Guile VM. It could still happen.
- bjoli 6y ago
  With the direction guile has been going in lately, guile is only becoming more attractive. The problem with integrating it is that you need someone with good knowledge about guile (since the elisp implementation is pretty bad currently) but even more important: someone who know Emacs internals (not many).

slightwinder 6y ago

Multi-decade effort..wasn't that done by just 2-3 guys as an alternative attempt? Anyway, while elisp might not be the fastest language around, it's not the origin of all slowness in emacs. Crufted design is also a big culprit. The dated regex-machine is often mentioned as a big problem, making syntax highlighting especially painful.

duckonomy 6y ago
Some people are saying that https://github.com/ubolonton/emacs-tree-sitter https://github.com/ubolonton/emacs-tree-sitter will eventually replace the default regexp-based font-lock for syntax highlighting. I'm personally testing it out and it's been great!
pmoriarty 6y ago
Apparently, Emacs' display code shares the blame, and no one wants to touch it as it's written in some really hairy legacy C. Though I'm not a Rust fan, and would infinitely prefer Guile Emacs, I am kind of half-hoping Remacs succeeds so Emacs can finally put all of that legacy C behind it.

LandR 6y ago

My experience on windows is that emacs is unusably slow. Multi-second lag on type and navigating isn't acceptable. Org-mode is especially bad.

jonrx 6y ago
I think it's related to the fact that emacs has multiple (very) small files and short-lived processes, which does not work well/fast on Windows. For a while, I ran Xubuntu in a VM just to use emacs, because the performance on my Surface book 2 was unacceptable. I ended up going in the other direction: kept emacs, got mostly rid of windows (I have it in a VM for the odd occasion where I need to use a windows-specific program. The fact that my company is flexible on the work OS is a huge bonus for me.