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.
On my M1 Mac 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?
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.
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!
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.
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.
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.
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.
> 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)
> 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).
> 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?
> But [monodraw]'s not open, and can't be edited by those who want to. We should always support FOSS.
> Absolutely we should. But [monodraw] isn't FOSS.
2.
> But [monodraw]'s not open, and can't be edited by those who want to. We should always support FOSS.
> Absolutely we should. But [monosketch] isn't FOSS.
The first interpretation makes no sense to me, because you've agreed completely with the parent comment but worded the comment in a way that sounds like you're disagreeing.
I think in this case the name alone is not enough to suspect a replacement; perhaps it’s just a similar product in the same domain (_mono_space visual editors).
Maybe it's just more or less feature-complete? Was curious, as someone who hadn't heard of it before, so I checked the blog. Last post is from April last year and concerns public testing of a new release. That's not particularly old, if you ask me?
There is a setting as of iOS 26 under "Privacy & Security > Wired Accessories" in which you can make data connections always prompt for access. Not that there haven't been bypasses for this before, but perhaps still of interest to you.
For me: pro & creative apps. GIMP/Inkscape will never replace Photoshop/Illustrator/Affinity. Ableton, Logic, Pro Tools, etc. are not available on Linux and with the exception of REAPER, the alternatives are awful. And even with a Linux-compatible DAW, very few plugins are available on Linux.
On macOS, I can work on hobby software & graphics/music.
This is a bit like claiming that a flat head screwdriver can sort of work with a Philips head screw… until it strips the head, you can’t see it and you don’t know how to fix it.
Not bad, but different DAWs cater to different workflows. To me (and most), Bitwig feels much more optimized for creating electronic music than recording guitar or drums. It wouldn't be my first choice for the latter workflow, where I'd prefer REAPER or Logic. You also still have the issue with plugin compatibility and that 99% of commercial plugin vendors don't support Linux.
> 99% of commercial plugin vendors don't support Linux.
It's a bit softened by the fact that many of them can be replaced/recreated with stock bitwig devices (if you're into that). There's also yabridge, though for me personally it has been a bit hit and miss.
The times of browsers having weirdly different rendering behavior are mostly gone, in my experience. I'm sure ~98% of Electron apps that expect Chromium would render just fine/same under WebKit as well.
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:
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.
reply