4 ms·

Tangential, but I really wish there would be a performance renaissance with Emacs. Native-comp was a good step forward, but Emacs is still so much slower than

Tangential, but I really wish there would be a performance renaissance with Emacs. Native-comp was a good step forward, but Emacs is still so much slower than Neovim, even in the case of launching and immediately quitting, with no config: $ time emacs -Q -e kill-emacs /Applications/Emacs.app/Contents/MacOS/Emacs -nw -Q -e kill-emacs 0.18s user 0.03s system 98% cpu 0.213 total $ time nvim -es --cmd 'vim.cmd("q")' nvim -es --cmd 'vim.cmd("q")' 0.02s user 0.01s system 82% cpu 0.034 total Even with a very minimal set of packages, text insertion, etc. is slower, and opening Magit (when it hasn't been loaded yet) takes about a second due to slow package loading. Emacs is my favorite editor, full stop. But every time I open Neovim or Sublime for quick tasks, it's always painfully apparent how much faster they are when I CMD+Tab back to Emacs.

ahoka 7mo ago
/usr/bin/time emacs -Q -e kill-emacs 0.03 real 0.02 user 0.00 sys Altough I'm not using Emacs.app.
- jonpalmisc 7mo ago
  Not using Emacs.app because you aren't on macOS, or using some other build/setup? If the latter, I'm curious.
ishouldbework 7mo ago
While faster Emacs would always be nice, I think the idea is you just keep it running. Hence emacsclient program. So startup time is not such a big deal.
- jonpalmisc 7mo ago
  Personally, I don't buy into this argument. I think having a globally shared buffer state, etc. is an antifeature. Plus, there's no reason that starting a TUI program should be that slow. Either way, this only addresses startup time too. The rest of the issues: text insertion lag, `project-find-file` being slow in large repos, etc. all remain.
  - dietr1ch 7mo ago
    > having a globally shared buffer state, etc. is an anti-feature Yeah, it feels a bit weird to not have some isolation. Spacemacs offers layouts[^1] that give you some buffer-isolation. Each window has a "layout", and layouts have sets of buffers. It works well, but you can run into extra prompts if you open the same buffer from two layouts and try to kill it from one of them (kill the buffer (for all layouts)? just remove from this layout? In my mind the latter should just be the default). [^1]: https://www.spacemacs.org/doc/DOCUMENTATION.html#layouts-and-workspaces https://www.spacemacs.org/doc/DOCUMENTATION.html#layouts-and...
  - smitty1e 7mo ago
    > I think having a globally shared buffer state, etc. is an antifeature. Maybe, but I'd like to hear why you think this is such an antifeature for a single-threaded application. Given the extra resources available these days, for example, why not just bring up a stand-alone ERC instance for chatting, if shared state is a concern?
  - chriswarbo 7mo ago
    > I think having a globally shared buffer state, etc. is an antifeature. As someone who mostly lives in Emacs, I like it. If I'm away from a machine, I can SSH into it and carry on with whatever I was in the middle of. It's also nice to set emacsclient as EDITOR, so that e.g. running `git commit` will open up a buffer in the existing Emacs session. This is especially useful since I use shell-mode, and it would be confusing/weird to have new Emacs instances popping up when I'm already in an editor! (They open in a "window" (i.e. pane) in the existing "frame" (i.e. window) instead)
  - ragall 7mo ago
    > Plus, there's no reason that starting a TUI program should be that slow. There's no reason why it shouldn't. You seem to think that the interface obliges a program into a certain performance pattern. No such obligation exists. And Emacs isn't a TUI program, it only happens to have a terminal interface among many others.
    - 7mo ago
dietr1ch 7mo ago
> Emacs is still so much slower than Neovim, even in the case of launching and immediately quitting I agree, but there's ways around it. On my machine the Emacs daemon is ready before I even log-in (lingering [^0]). I think I only restart the daemon when I update emacs and its packages, and yeah, Emacs and Spacemacs are slow, but do not slow me down. [^0]: https://wiki.archlinux.org/title/Systemd/User#Automatic_start-up_of_systemd_user_instances https://wiki.archlinux.org/title/Systemd/User#Automatic_star...
8s2ngy 7mo ago
I share your wish. Emacs, as wonderful as it is, has accumulated a lot of cruft over the decades and would benefit immensely from a rewrite. A "Neo-Emacs" could be multithreaded from the ground up and drop support for archaic platforms. The rewrite could even be in Rust to attract younger developers.
- School-Cotton 7mo ago
  There would be no point to writing emacs in a language that can’t be developed interactively in a repl. Emacs being written in lisp is an essential quality.
  - BigTTYGothGF 7mo ago
    > Emacs being written in lisp is an essential quality Not for the parts of it I use.
- precompute 7mo ago
  >a lot of cruft Like what? Emacs is written in C and there are ports of it out there (all half-abandoned). Emacs, the way it exists, works very well.
  - School-Cotton 7mo ago
    The vast majority of emacs is written in lisp, not C.
chriswarbo 7mo ago
Emacs can certainly be sluggish, but I'm not sure how much that's e.g. inherent to ELisp, or due to synchronous/single-threaded code, or choosing slow algorithms for certain tasks, etc. For me, the best performance improvement has been handling long lines; e.g. Emacs used to become unusable if it was given a line of around 1MB. Since I run lots of shell-mode buffers, that would happen frustratingly-often. My workaround was to make my default shell a script that pipes `bash` through a pared-down, zero-allocation copy of GNU `fold`, to force a newline after hitting a certain length (crossing a lower threshold would break at the next whitespace; hitting an upper threshold would force a break immediately). That piping caused Bash to think it wasn't interactive, which required another work-around using Expect. Thankfully the last few versions of Emacs have fixed long-line handling enough for me to get rid of my awful Rube-Goldberg shell!
BigTTYGothGF 7mo ago
I'm not sure I'm capable of noticing or caring about the difference between 0.18 and 0.02 seconds for something that doesn't happen on a rapid cadence.
spudlyo 7mo ago
On my M1 Mac Pro I get 0.13s wall, so not much faster than your Mac. On my i9-9900K Linux box I get 0.04s. I would think my M1 single core performance would be on par, if not faster. Perhaps it has something to do with macOS and gatekeeper, as I notice I'm not getting as high of a CPU utilization. $ gtime /opt/homebrew/bin/emacs --batch --eval '(princ (format "%s\n" emacs-version))' 30.2 0.07user 0.03system 0:00.13elapsed 78%CPU (0avgtext+0avgdata 46064maxresident)k $ /usr/bin/time ~/bin/emacs --batch -eval '(princ (format "%s\n" emacs-version))' 30.2 0.02user 0.01system 0:00.04elapsed 95%CPU (0avgtext+0avgdata 57728maxresident)k
- frantathefranta 7mo ago
  GUI Emacs on a 12 year old processor (i5-4590) feels faster than on a M4 Pro Macbook. I think it's just something to do with the window manager on each of the systems (my experience is mostly with Wayland KDE) rather than the speed of the CPU.
  - spudlyo 7mo ago
    I also run GUI Emacs on both Linux and macOS. I build it on Linux with --with-x-toolkit=lucid and for $REASONS I'm still on X11. I run it in a full-screen frame on its own monitor, and it does indeed feel faster.
Joe_Cool 7mo ago
What hardware are you on? On my old Ryzen 3600X running Arch it's a lot faster. Does the UI eat so much performance on OSX? $ time emacs -Q -e kill-emacs real 0m0.076s user 0m0.058s sys 0m0.018s $ time nvim -es --cmd 'vim.cmd("q")' real 0m0.028s user 0m0.005s sys 0m0.003s vim still is a lot faster though.
- znpy 7mo ago
  > On my old Ryzen 3600X running Arch > vim still is a lot faster though. you might want to make sure you're comparing apples to apples though. the "emacs" command most likely is going to load the GUI emacs so a lot of gui libraries (if you're running a recent emacs then even GTK libraries) whereas the nvim command isn't going to load gui libraries at all. maybe try with a non-gui version of emacs (or maybe calling emacs -nw)
  - Joe_Cool 7mo ago
    no, this is the TUI version. X11 emacs with all the composited effects needs about 200-250ms to open (about the duration of the animation for opening and closing it). That's more like OP's timings.
    - codygman 7mo ago
      No, you need to use -nw with emacs to make it apples to apples. Then it's emacs 0m0.095s vs nvim 0m0.057s: $ time nvim -es --cmd 'vim.cmd("q")' real 0m0.057s user 0m0.016s sys 0m0.017s $ time emacs -Q -e kill-emacs real 0m0.230s user 0m0.165s sys 0m0.064s $ time emacs -nw -Q -e kill-emacs real 0m0.095s user 0m0.057s sys 0m0.017s
      - Joe_Cool 7mo ago
        Shouldn't matter when I am not on GUI seat. In my SSH session with X11 forwarding there is no DISPLAY emacs could use. Tried it anyways, looks the same: $ time emacs -nw -Q -e kill-emacs real 0m0.075s user 0m0.062s sys 0m0.013s
precompute 7mo ago
Startup time does not matter, use the daemon. Opening a new frame is ~instantaneous. I practically live in Emacs and it's not slow at all. It's very zippy, and my setup isn't the lightest! There's a new branch (feature/igc) with incremental garbage collection (via MPS) that makes routine actions faster. I've been using it and it has been incredibly stable and has completely eliminated stutters (which used to happen very infrequently, but were present). Also, to me, it seems like it improves latency. The cursor feels more responsive.
- znpy 7mo ago
  > I practically live in Emacs and it's not slow at all. It's very zippy, and my setup isn't the lightest! yeah, that's been my experience as well, particularly since upgrading to releases 29 and 30 where native compilation was enabled by default. honestly the only place where it's slow it's when i'm editing terraform files, but that's because it needs to boot the terraform language server, and only on the first file of the project.
zelphirkalt 7mo ago
Emacs' hard to solve issue is its use of global mutable state all across the board, which makes concurrency and parallelism very hard to add properly. It will take a lot of effort to slowly carefully reduce the error/bug surface and add proper parallelism constructs, that are easy to use for any package author.
- truncate 7mo ago
  Emacs is my editor/IDE of choice and consider myself power-user. However, I'm no expert in its internals or elisp. I understand that things are built with single-thread execution in mind over decades. However, I think things still can be more async, where you can offload heavy stuff to separate thread and stream results. E.g. Magit status doesn't need to block my entire editor. It can run what it needs to do in separate thread, send the results back to main thread just for rendering when its ready. Same with say consult-ripgrep / consult-find-file / find-file-in-project etc -- doens't need to wait for it in main thread and block the render / event handling until entire result set is ready (e.g. in this case things can be streamed). As in maybe there is a way around to make this much better by message passing/streaming instead of sharing state itself? I love Emacs, but it really just fails to be effective for me when I work on monorepos and even more so, when I'm on tramp.
  - zelphirkalt 7mo ago
    Probably all true, what you say about magit and so on. Message passing values would be an idea, but with the current situation, when 1 concurrent execution units, a process, finishes its job, how does its "private" potentially modified state get merged back into the main Emacs global state? Lets say the concurrently running process creates some buffers to show, but in the meantime the user has rearranged their windows or split their view, but the concurrent process doesn't know about that, since it was after its creation time. Or maybe the user has meanwhile changed an important Emacs setting. I think the current solutions for running things in separate threads are only for external tools. I guess to do more, a kind of protocol would need to be invented, that tells a process exactly what parts of the copied global state it may change and when it finishes, only those parts will be merged back into the main process' global state. Maybe I understood things wrong and things are different than I understood them to be. I am not an Emacs core developer. Just a user, who watched a few videos. Tramp can be sped up a bit. I remember seeing some blog posts about it. I guess if you need to go via more than 1 hop, it can get slow though. What is the problem with mono repos?
Ferret7446 7mo ago
Emacs is functionally a shell not an editor. Starting Emacs for each file is akin to starting and stopping Wayland for every web page you open. So the miniscule increase in start time is a non issue
weaksauce 7mo ago
my non-command line gui version of doom emacs with a bunch of packages enabled loads up fully for me in 0.45s which is hardly slow. sure it's slower than neovim but also not slow in the absolute sense and i don't have the emacs daemon running which would make that even faster.
rurban 7mo ago
You never close emacs. You never open a new emacs. You tell emacsclient which file to load and to which line to jump to. For me that's `e file.ext:200` expanding to a emacsclient call.

ahoka 7mo ago

/usr/bin/time emacs -Q -e kill-emacs 0.03 real 0.02 user 0.00 sys Altough I'm not using Emacs.app.

jonpalmisc 7mo ago
Not using Emacs.app because you aren't on macOS, or using some other build/setup? If the latter, I'm curious.

ishouldbework 7mo ago

While faster Emacs would always be nice, I think the idea is you just keep it running. Hence emacsclient program. So startup time is not such a big deal.

jonpalmisc 7mo ago
Personally, I don't buy into this argument. I think having a globally shared buffer state, etc. is an antifeature. Plus, there's no reason that starting a TUI program should be that slow. Either way, this only addresses startup time too. The rest of the issues: text insertion lag, `project-find-file` being slow in large repos, etc. all remain.
- dietr1ch 7mo ago
  > having a globally shared buffer state, etc. is an anti-feature Yeah, it feels a bit weird to not have some isolation. Spacemacs offers layouts[^1] that give you some buffer-isolation. Each window has a "layout", and layouts have sets of buffers. It works well, but you can run into extra prompts if you open the same buffer from two layouts and try to kill it from one of them (kill the buffer (for all layouts)? just remove from this layout? In my mind the latter should just be the default). [^1]: https://www.spacemacs.org/doc/DOCUMENTATION.html#layouts-and-workspaces https://www.spacemacs.org/doc/DOCUMENTATION.html#layouts-and...
- smitty1e 7mo ago
  > I think having a globally shared buffer state, etc. is an antifeature. Maybe, but I'd like to hear why you think this is such an antifeature for a single-threaded application. Given the extra resources available these days, for example, why not just bring up a stand-alone ERC instance for chatting, if shared state is a concern?
- chriswarbo 7mo ago
  > I think having a globally shared buffer state, etc. is an antifeature. As someone who mostly lives in Emacs, I like it. If I'm away from a machine, I can SSH into it and carry on with whatever I was in the middle of. It's also nice to set emacsclient as EDITOR, so that e.g. running `git commit` will open up a buffer in the existing Emacs session. This is especially useful since I use shell-mode, and it would be confusing/weird to have new Emacs instances popping up when I'm already in an editor! (They open in a "window" (i.e. pane) in the existing "frame" (i.e. window) instead)
- ragall 7mo ago
  > Plus, there's no reason that starting a TUI program should be that slow. There's no reason why it shouldn't. You seem to think that the interface obliges a program into a certain performance pattern. No such obligation exists. And Emacs isn't a TUI program, it only happens to have a terminal interface among many others.
  - 7mo ago

dietr1ch 7mo ago

> Emacs is still so much slower than Neovim, even in the case of launching and immediately quitting I agree, but there's ways around it. On my machine the Emacs daemon is ready before I even log-in (lingering [^0]). I think I only restart the daemon when I update emacs and its packages, and yeah, Emacs and Spacemacs are slow, but do not slow me down. [^0]: https://wiki.archlinux.org/title/Systemd/User#Automatic_start-up_of_systemd_user_instances https://wiki.archlinux.org/title/Systemd/User#Automatic_star...

8s2ngy 7mo ago

I share your wish. Emacs, as wonderful as it is, has accumulated a lot of cruft over the decades and would benefit immensely from a rewrite. A "Neo-Emacs" could be multithreaded from the ground up and drop support for archaic platforms. The rewrite could even be in Rust to attract younger developers.

School-Cotton 7mo ago
There would be no point to writing emacs in a language that can’t be developed interactively in a repl. Emacs being written in lisp is an essential quality.
- BigTTYGothGF 7mo ago
  > Emacs being written in lisp is an essential quality Not for the parts of it I use.
precompute 7mo ago
>a lot of cruft Like what? Emacs is written in C and there are ports of it out there (all half-abandoned). Emacs, the way it exists, works very well.
- School-Cotton 7mo ago
  The vast majority of emacs is written in lisp, not C.

chriswarbo 7mo ago

Emacs can certainly be sluggish, but I'm not sure how much that's e.g. inherent to ELisp, or due to synchronous/single-threaded code, or choosing slow algorithms for certain tasks, etc. For me, the best performance improvement has been handling long lines; e.g. Emacs used to become unusable if it was given a line of around 1MB. Since I run lots of shell-mode buffers, that would happen frustratingly-often. My workaround was to make my default shell a script that pipes `bash` through a pared-down, zero-allocation copy of GNU `fold`, to force a newline after hitting a certain length (crossing a lower threshold would break at the next whitespace; hitting an upper threshold would force a break immediately). That piping caused Bash to think it wasn't interactive, which required another work-around using Expect. Thankfully the last few versions of Emacs have fixed long-line handling enough for me to get rid of my awful Rube-Goldberg shell!

BigTTYGothGF 7mo ago

I'm not sure I'm capable of noticing or caring about the difference between 0.18 and 0.02 seconds for something that doesn't happen on a rapid cadence.

spudlyo 7mo ago

On my M1 Mac Pro I get 0.13s wall, so not much faster than your Mac. On my i9-9900K Linux box I get 0.04s. I would think my M1 single core performance would be on par, if not faster. Perhaps it has something to do with macOS and gatekeeper, as I notice I'm not getting as high of a CPU utilization. $ gtime /opt/homebrew/bin/emacs --batch --eval '(princ (format "%s\n" emacs-version))' 30.2 0.07user 0.03system 0:00.13elapsed 78%CPU (0avgtext+0avgdata 46064maxresident)k $ /usr/bin/time ~/bin/emacs --batch -eval '(princ (format "%s\n" emacs-version))' 30.2 0.02user 0.01system 0:00.04elapsed 95%CPU (0avgtext+0avgdata 57728maxresident)k

frantathefranta 7mo ago
GUI Emacs on a 12 year old processor (i5-4590) feels faster than on a M4 Pro Macbook. I think it's just something to do with the window manager on each of the systems (my experience is mostly with Wayland KDE) rather than the speed of the CPU.
- spudlyo 7mo ago
  I also run GUI Emacs on both Linux and macOS. I build it on Linux with --with-x-toolkit=lucid and for $REASONS I'm still on X11. I run it in a full-screen frame on its own monitor, and it does indeed feel faster.

Joe_Cool 7mo ago

What hardware are you on? On my old Ryzen 3600X running Arch it's a lot faster. Does the UI eat so much performance on OSX? $ time emacs -Q -e kill-emacs real 0m0.076s user 0m0.058s sys 0m0.018s $ time nvim -es --cmd 'vim.cmd("q")' real 0m0.028s user 0m0.005s sys 0m0.003s vim still is a lot faster though.

znpy 7mo ago
> On my old Ryzen 3600X running Arch > vim still is a lot faster though. you might want to make sure you're comparing apples to apples though. the "emacs" command most likely is going to load the GUI emacs so a lot of gui libraries (if you're running a recent emacs then even GTK libraries) whereas the nvim command isn't going to load gui libraries at all. maybe try with a non-gui version of emacs (or maybe calling emacs -nw)
- Joe_Cool 7mo ago
  no, this is the TUI version. X11 emacs with all the composited effects needs about 200-250ms to open (about the duration of the animation for opening and closing it). That's more like OP's timings.
  - codygman 7mo ago
    No, you need to use -nw with emacs to make it apples to apples. Then it's emacs 0m0.095s vs nvim 0m0.057s: $ time nvim -es --cmd 'vim.cmd("q")' real 0m0.057s user 0m0.016s sys 0m0.017s $ time emacs -Q -e kill-emacs real 0m0.230s user 0m0.165s sys 0m0.064s $ time emacs -nw -Q -e kill-emacs real 0m0.095s user 0m0.057s sys 0m0.017s
    - Joe_Cool 7mo ago
      Shouldn't matter when I am not on GUI seat. In my SSH session with X11 forwarding there is no DISPLAY emacs could use. Tried it anyways, looks the same: $ time emacs -nw -Q -e kill-emacs real 0m0.075s user 0m0.062s sys 0m0.013s

precompute 7mo ago

Startup time does not matter, use the daemon. Opening a new frame is ~instantaneous. I practically live in Emacs and it's not slow at all. It's very zippy, and my setup isn't the lightest! There's a new branch (feature/igc) with incremental garbage collection (via MPS) that makes routine actions faster. I've been using it and it has been incredibly stable and has completely eliminated stutters (which used to happen very infrequently, but were present). Also, to me, it seems like it improves latency. The cursor feels more responsive.

znpy 7mo ago
> I practically live in Emacs and it's not slow at all. It's very zippy, and my setup isn't the lightest! yeah, that's been my experience as well, particularly since upgrading to releases 29 and 30 where native compilation was enabled by default. honestly the only place where it's slow it's when i'm editing terraform files, but that's because it needs to boot the terraform language server, and only on the first file of the project.

zelphirkalt 7mo ago

Emacs' hard to solve issue is its use of global mutable state all across the board, which makes concurrency and parallelism very hard to add properly. It will take a lot of effort to slowly carefully reduce the error/bug surface and add proper parallelism constructs, that are easy to use for any package author.

truncate 7mo ago
Emacs is my editor/IDE of choice and consider myself power-user. However, I'm no expert in its internals or elisp. I understand that things are built with single-thread execution in mind over decades. However, I think things still can be more async, where you can offload heavy stuff to separate thread and stream results. E.g. Magit status doesn't need to block my entire editor. It can run what it needs to do in separate thread, send the results back to main thread just for rendering when its ready. Same with say consult-ripgrep / consult-find-file / find-file-in-project etc -- doens't need to wait for it in main thread and block the render / event handling until entire result set is ready (e.g. in this case things can be streamed). As in maybe there is a way around to make this much better by message passing/streaming instead of sharing state itself? I love Emacs, but it really just fails to be effective for me when I work on monorepos and even more so, when I'm on tramp.
- zelphirkalt 7mo ago
  Probably all true, what you say about magit and so on. Message passing values would be an idea, but with the current situation, when 1 concurrent execution units, a process, finishes its job, how does its "private" potentially modified state get merged back into the main Emacs global state? Lets say the concurrently running process creates some buffers to show, but in the meantime the user has rearranged their windows or split their view, but the concurrent process doesn't know about that, since it was after its creation time. Or maybe the user has meanwhile changed an important Emacs setting. I think the current solutions for running things in separate threads are only for external tools. I guess to do more, a kind of protocol would need to be invented, that tells a process exactly what parts of the copied global state it may change and when it finishes, only those parts will be merged back into the main process' global state. Maybe I understood things wrong and things are different than I understood them to be. I am not an Emacs core developer. Just a user, who watched a few videos. Tramp can be sped up a bit. I remember seeing some blog posts about it. I guess if you need to go via more than 1 hop, it can get slow though. What is the problem with mono repos?

Ferret7446 7mo ago

Emacs is functionally a shell not an editor. Starting Emacs for each file is akin to starting and stopping Wayland for every web page you open. So the miniscule increase in start time is a non issue

weaksauce 7mo ago

my non-command line gui version of doom emacs with a bunch of packages enabled loads up fully for me in 0.45s which is hardly slow. sure it's slower than neovim but also not slow in the absolute sense and i don't have the emacs daemon running which would make that even faster.

rurban 7mo ago

You never close emacs. You never open a new emacs. You tell emacsclient which file to load and to which line to jump to. For me that's `e file.ext:200` expanding to a emacsclient call.