7 ms·

I want to love emacs I really do. Couple things that I really get hung up on MELPA isn't user friendly - I don't mean in the usability sense. The maintainers r

I want to love emacs I really do. Couple things that I really get hung up on MELPA isn't user friendly - I don't mean in the usability sense. The maintainers routinely remove packages that are being used. Breaking your end-user's dependencies for non-security related reasons seems unusual for a package repository. If it goes into MELPA and a user has downloaded it, it should stay there for basically forever or as long as feasible. Performance - emacs is noticeably slow even on latest Apple hardware and I can't seem to get to it to an acceptable performance level. The bar for acceptable for me is VS Code.

perihelions 3y ago
- "Performance - emacs is noticeably slow even on latest Apple hardware and I can't seem to get to it to an acceptable performance level. The bar for acceptable for me is VS Code." Is it plain Emacs that's noticeably slow, or Emacs after installing 3rd-party packages? Some of the popular ones are very performance-costly.
- dingnuts 3y ago
  before native compilation Emacs itself was pretty dang slow on its own, and you probably have to compile yourself to get nativecomp (which won't always be true) depending on the distro you're using etc
  - armitron 3y ago
    nativecomp is pretty much a gimmick and should make absolutely no difference in perceived Emacs slowness during actual usage and not stupid microbenchmarks.
    - ParetoOptimal 3y ago
      This is absolutely not true. I mistakingly used an emacs without native compilation and very much noticed in large org buffers.
    - techbro92 3y ago
      Really? Do you have any links to explain this? I find this to be a super unintuitive result because I would expect compiled code to be faster than interpreted. My recommendation for native compiling is just based on personal experience not benchmarks. Emacs feels faster after enabling it.
      - deleted 3y ago
        [deleted]
    - TacticalCoder 3y ago
      > nativecomp is pretty much a gimmick and should make absolutely no difference in perceived Emacs slowness during actual usage and not stupid microbenchmarks. That is completely wrong. I'm using Emacs back since when I was compiling it on 486 with 8 MB of RAM. nativecomp is the single biggest speed boost I saw Emacs ever getting. Using Emacs on the same machine with nativecomp on or not was night and day (a Core i7-6700 in my case: maybe the difference would be less noticeable nowadays but I couldn't tell as I now only ever run nativecomp and compile it with nativecomp on). You're the first person I ever hear saying nativecomp doesn't make a difference.
    - dingnuts 3y ago
      well, it does make a difference in the perceived slowness, so something about your mental model of what nativecomp does, must be incorrect. I compile Emacs from source specifically to get nativecomp because of the obviously perceptible difference in performance. Maybe you have a much faster computer than the rest of us?
- avgcorrection 3y ago
  Plain Emacs is not Emacs. Customization or at least the option to customize is the whole point.
techbro92 3y ago
I highly recommend compiling emacs from source with the option for native lisp compilation enabled. Emacs is way faster when you do this.
- armitron 3y ago
  Everyone that recommends nativecomp as a way to fix perceived Emacs slowness in this topic is basically parroting something that's completely and utterly wrong. Native compilation should make no difference in perceived "slowness" for the vast majority of real-world use cases.
  - taeric 3y ago
    I'm curious why you think that? Certainly "use your faster computer" is more impactful, but I definitely feel things are a bit faster with native enabled.
armitron 3y ago
Run 'emacs -q' (no add-ons loaded) and it should be a lot faster than VS Code. Which means that a library you loaded is the culprit. Things like Doom Emacs are notorious for unexpected slowness since they're not very well put together and load questionable libraries. In the unlikely case where emacs -q is still slow, use Emacs Mac Port (https://github.com/railwaycat/homebrew-emacsmacport/releases/tag/emacs-29.1-mac-10.0 https://github.com/railwaycat/homebrew-emacsmacport/releases...). This is at least 2x perceivably faster than VS Code on Mac.
iLemming 3y ago
> The bar for acceptable for me is VS Code. Hmm. I have quite the opposite complain. Why is when I install a single extension that enables Vim navigation in VSCode there's quite noticeable typing latency? And it's not a single plugin, I tried multiple. While my Emacs instance where I use over 300, built-in and third-party packages still feels quite snappy. I'm not saying that Emacs built in such a way that it is impossible for a package to degrade its performance, that can happen, but if you know how to use the built-in profiler it's not that difficult to find the culprit and either remove it or try to find a workaround. While typing this comment I googled, TIL - VSCode has very impressive Perf Tools suite for profiling. That makes it even more surprising, why would the authors of those Vim plugins, and I'm not talking about some obscure and esoteric thing, but supposedly popular, demanded feature, ship it with such obvious deficiency? Observing this latency after adding just a single extension, frankly makes me question the long-term viability of using VSCode as my main code editor.
- kamaal 3y ago
  Well vscode is vscode, vim is vim. Don't get me wrong, I use vim a lot and I tend to use macros as a rudimentary text automation language. And I use it all the time on servers, because its universally installed. Mixing these things is pointless because you are fighting both and getting nowhere. Learning vim definitely has its use. But both vim and emacs have lost the code tooling wars long back. You can configure emacs and vim to to anything. And that is not a win vim/emacs users think it is. Nearly all the programmers out there don't want to spend time on sub projects, just to bring their tools to bare minimal working standards modern tooling provides out of the box. vscode just works, it works out of the box, for 99% of the use cases out there and it works phenomenally well. Plus the whole idea of being able to write out code faster, or navigate faster made sense in UI paradigms of the old, where there were no windows, and a overall better UI experience. These days coding and navigation speed aren't even in the ballpark of factors that slow me down as a programmer. And yeah, Org mode. Unfortunately Google docs do way more, and you don't have to remember dozens of commands to just make simple tables, add dates and bullet points. In many ways Richard Stallman had an idea that emacs should have really had a WYSIWYG facilities. But Google Docs go even one step further as everything is saved on a cloud and you don't really have to worry about losing anything at all. Emacs on the other hand is a great time pass hacking tool, if you are bored or just want to work on something cool.
iLemming 3y ago
> nativecomp is pretty much a gimmick I wouldn't go so far as to call native-comp feature a gimmick, but you probably won't see noticeable UI performance improvements with it. On the Mac, --with-metal support may give it a bit snappier feel but it depends on the hardware, you may try both, with and without and compare. Matter of fact, Emacs with native-comp flag may give you an impression of things being super slow right after the startup, because it often has to recompile packages asynchronously, the process of which you can observe in *Async-native-compile-log* buffer, it's normal for Emacs built with native-comp to be a bit laggy for a minute or two at the startup, but you don't have to restart Emacs very often. native-comp benefits can be observed when using things like lsp-mode, where it brings some good perf improvements, sometimes it's worth it, but you also have to expect things to break, and quite often, native-comp relies on libgccjit, and MacOS updates often break the toolchain dependencies, and it can be highly annoying if you like to update Emacs packages often, especially when using something like Doom or Spacemacs, but it's not Emacs' fault. It's great that we have the option to disable native-comp completely without having drastically reduced performance, most of the time, you won't even notice it. Also, one thing I always recommend doing on the Mac, which is absolutely unrelated to Emacs is this: ```bash # "Set a blazingly fast keyboard repeat rate, " defaults write NSGlobalDomain KeyRepeat -int 1 # "Set a shorter Delay until key repeat" defaults write NSGlobalDomain InitialKeyRepeat -int 10 # disable accents on key hold defaults write -g ApplePressAndHoldEnabled -bool false ``` Reboot after setting that and trust me, you'd thank me later. Emacs would feel like it's on steroids. And remember, don't ever change repeat rate in Preferences dialog, it resets it to the values acceptable for muggles. Don't be one, be the keyboard wizard, let your machine fly.
- logicprog 3y ago
  Doom Emacs actually compiles your packages ahead of time before your editor even starts, which is a dog slow process to go through when you do it, but you only have to do it once and then your editor is as snappy as you could want. My Doom (which has a lot of layers enabled) starts in 0.17s iirc
  - iLemming 3y ago
logicprog 3y ago
I switched from VS Code to Doom Emacs last year (I had been using Spacemacs before that) and my Emacs is infinitely faster than a similarly configured (homologous extensions, etc) VS Code. So I suspect it might have something to do with your configuration?

perihelions 3y ago

- "Performance - emacs is noticeably slow even on latest Apple hardware and I can't seem to get to it to an acceptable performance level. The bar for acceptable for me is VS Code." Is it plain Emacs that's noticeably slow, or Emacs after installing 3rd-party packages? Some of the popular ones are very performance-costly.

dingnuts 3y ago
before native compilation Emacs itself was pretty dang slow on its own, and you probably have to compile yourself to get nativecomp (which won't always be true) depending on the distro you're using etc
- armitron 3y ago
  nativecomp is pretty much a gimmick and should make absolutely no difference in perceived Emacs slowness during actual usage and not stupid microbenchmarks.
  - ParetoOptimal 3y ago
    This is absolutely not true. I mistakingly used an emacs without native compilation and very much noticed in large org buffers.
  - techbro92 3y ago
    Really? Do you have any links to explain this? I find this to be a super unintuitive result because I would expect compiled code to be faster than interpreted. My recommendation for native compiling is just based on personal experience not benchmarks. Emacs feels faster after enabling it.
    - deleted 3y ago
      [deleted]
  - TacticalCoder 3y ago
    > nativecomp is pretty much a gimmick and should make absolutely no difference in perceived Emacs slowness during actual usage and not stupid microbenchmarks. That is completely wrong. I'm using Emacs back since when I was compiling it on 486 with 8 MB of RAM. nativecomp is the single biggest speed boost I saw Emacs ever getting. Using Emacs on the same machine with nativecomp on or not was night and day (a Core i7-6700 in my case: maybe the difference would be less noticeable nowadays but I couldn't tell as I now only ever run nativecomp and compile it with nativecomp on). You're the first person I ever hear saying nativecomp doesn't make a difference.
  - dingnuts 3y ago
    well, it does make a difference in the perceived slowness, so something about your mental model of what nativecomp does, must be incorrect. I compile Emacs from source specifically to get nativecomp because of the obviously perceptible difference in performance. Maybe you have a much faster computer than the rest of us?
avgcorrection 3y ago
Plain Emacs is not Emacs. Customization or at least the option to customize is the whole point.

techbro92 3y ago

I highly recommend compiling emacs from source with the option for native lisp compilation enabled. Emacs is way faster when you do this.

armitron 3y ago
Everyone that recommends nativecomp as a way to fix perceived Emacs slowness in this topic is basically parroting something that's completely and utterly wrong. Native compilation should make no difference in perceived "slowness" for the vast majority of real-world use cases.
- taeric 3y ago
  I'm curious why you think that? Certainly "use your faster computer" is more impactful, but I definitely feel things are a bit faster with native enabled.

armitron 3y ago

Run 'emacs -q' (no add-ons loaded) and it should be a lot faster than VS Code. Which means that a library you loaded is the culprit. Things like Doom Emacs are notorious for unexpected slowness since they're not very well put together and load questionable libraries. In the unlikely case where emacs -q is still slow, use Emacs Mac Port (https://github.com/railwaycat/homebrew-emacsmacport/releases/tag/emacs-29.1-mac-10.0 https://github.com/railwaycat/homebrew-emacsmacport/releases...). This is at least 2x perceivably faster than VS Code on Mac.

iLemming 3y ago

> The bar for acceptable for me is VS Code. Hmm. I have quite the opposite complain. Why is when I install a single extension that enables Vim navigation in VSCode there's quite noticeable typing latency? And it's not a single plugin, I tried multiple. While my Emacs instance where I use over 300, built-in and third-party packages still feels quite snappy. I'm not saying that Emacs built in such a way that it is impossible for a package to degrade its performance, that can happen, but if you know how to use the built-in profiler it's not that difficult to find the culprit and either remove it or try to find a workaround. While typing this comment I googled, TIL - VSCode has very impressive Perf Tools suite for profiling. That makes it even more surprising, why would the authors of those Vim plugins, and I'm not talking about some obscure and esoteric thing, but supposedly popular, demanded feature, ship it with such obvious deficiency? Observing this latency after adding just a single extension, frankly makes me question the long-term viability of using VSCode as my main code editor.

kamaal 3y ago
Well vscode is vscode, vim is vim. Don't get me wrong, I use vim a lot and I tend to use macros as a rudimentary text automation language. And I use it all the time on servers, because its universally installed. Mixing these things is pointless because you are fighting both and getting nowhere. Learning vim definitely has its use. But both vim and emacs have lost the code tooling wars long back. You can configure emacs and vim to to anything. And that is not a win vim/emacs users think it is. Nearly all the programmers out there don't want to spend time on sub projects, just to bring their tools to bare minimal working standards modern tooling provides out of the box. vscode just works, it works out of the box, for 99% of the use cases out there and it works phenomenally well. Plus the whole idea of being able to write out code faster, or navigate faster made sense in UI paradigms of the old, where there were no windows, and a overall better UI experience. These days coding and navigation speed aren't even in the ballpark of factors that slow me down as a programmer. And yeah, Org mode. Unfortunately Google docs do way more, and you don't have to remember dozens of commands to just make simple tables, add dates and bullet points. In many ways Richard Stallman had an idea that emacs should have really had a WYSIWYG facilities. But Google Docs go even one step further as everything is saved on a cloud and you don't really have to worry about losing anything at all. Emacs on the other hand is a great time pass hacking tool, if you are bored or just want to work on something cool.

iLemming 3y ago

> nativecomp is pretty much a gimmick I wouldn't go so far as to call native-comp feature a gimmick, but you probably won't see noticeable UI performance improvements with it. On the Mac, --with-metal support may give it a bit snappier feel but it depends on the hardware, you may try both, with and without and compare. Matter of fact, Emacs with native-comp flag may give you an impression of things being super slow right after the startup, because it often has to recompile packages asynchronously, the process of which you can observe in *Async-native-compile-log* buffer, it's normal for Emacs built with native-comp to be a bit laggy for a minute or two at the startup, but you don't have to restart Emacs very often. native-comp benefits can be observed when using things like lsp-mode, where it brings some good perf improvements, sometimes it's worth it, but you also have to expect things to break, and quite often, native-comp relies on libgccjit, and MacOS updates often break the toolchain dependencies, and it can be highly annoying if you like to update Emacs packages often, especially when using something like Doom or Spacemacs, but it's not Emacs' fault. It's great that we have the option to disable native-comp completely without having drastically reduced performance, most of the time, you won't even notice it. Also, one thing I always recommend doing on the Mac, which is absolutely unrelated to Emacs is this: ```bash # "Set a blazingly fast keyboard repeat rate, " defaults write NSGlobalDomain KeyRepeat -int 1 # "Set a shorter Delay until key repeat" defaults write NSGlobalDomain InitialKeyRepeat -int 10 # disable accents on key hold defaults write -g ApplePressAndHoldEnabled -bool false ``` Reboot after setting that and trust me, you'd thank me later. Emacs would feel like it's on steroids. And remember, don't ever change repeat rate in Preferences dialog, it resets it to the values acceptable for muggles. Don't be one, be the keyboard wizard, let your machine fly.

logicprog 3y ago
Doom Emacs actually compiles your packages ahead of time before your editor even starts, which is a dog slow process to go through when you do it, but you only have to do it once and then your editor is as snappy as you could want. My Doom (which has a lot of layers enabled) starts in 0.17s iirc
- iLemming 3y ago

logicprog 3y ago

I switched from VS Code to Doom Emacs last year (I had been using Spacemacs before that) and my Emacs is infinitely faster than a similarly configured (homologous extensions, etc) VS Code. So I suspect it might have something to do with your configuration?