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 :).

Also Emacs can lock the rest of the panes while doing I/O.

How could native code solve that?

Guile at least could.

What's your machine specs ?

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.

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.

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).

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.

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.

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.

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.

I think the reason that emacs feels fine most of the time even if elisp is slow is that usually abstractions are fairly minimal.

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

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.

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.

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.

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.

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.

Speaking as recent(4-5 months) Emacs(spacemacs) convert - it is slower compared to even "decked out" vim. An important caveat to mention is that it very much depends on what modes you are operating in -- each file type will usually operate in its own mode, with varying performance. In my experience the lagginess is rare, but its very workflow dependent, there's this one large(1.5k line) php file I have to edit semi-regularly on which I switch off the php mode, just to avoid the pain of jankiness. It isn't very noticeable in other, "regular" sized files.

But overall I'm a very happy emacs convert. It's extremely malleable and pleasant development environment and I think it definitely deserves all the gushing articles/posts its been receiving past few years.

Spacemacs is actually quite a bit slower than it probably needs to be (by which I mean "slower than Doom emacs [https://github.com/hlissner/doom-emacs]").

I don't know the reason but for me Emacs is frustratingly slow compared to Vim.

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.

Some people are saying that 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!

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.

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

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.

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.