6 ms·

The speedup is very noticeable. Like others I'm running the "native-comp" branch of Emacs, since months, without any issue. It's now been merged into trunk and

The speedup is very noticeable. Like others I'm running the "native-comp" branch of Emacs, since months, without any issue. It's now been merged into trunk and it's going to be the default: https://news.ycombinator.com/item?id=26935401 https://news.ycombinator.com/item?id=26935401 The only drawback I saw is that compiling Emacs itself takes 3x to 4x longer when compiling the native-comp branch.

ashton314 5y ago
I tried this on macOS a few months ago and it was pretty rocky just getting the thing compiled. I tried again last night and it pretty much Just Worked(tm) thanks to this[1] project. Note: this was on an Intel mac; anyone with an M1 tried this yet? I did run into some problems with some newer packages on the GNU ELPA. (Specifically consult, marginalia, and vertico by github.com/minad) Straight.el complained about not being able to find the packages. Any suggestions on what I might try to fix this? [1]: https://github.com/jimeh/build-emacs-for-macos https://github.com/jimeh/build-emacs-for-macos
- deleted 5y ago
  [deleted]
- TacticalCoder 5y ago
  Can't help as I'm on Linux (also I use ivy/avy/counsel and not consult/marginalia/vertico).
  - dmd 5y ago
    Out of curiosity, why did you reply?
    - ashton314 5y ago
      He was replying to some questions I asked him in my reply to his top-level post. I was confused too, but now that I figured it out, I appreciate the reply.
- erk__ 5y ago
  Maybe try and write out the complete path for the github repo when using straight, I am using the abo e packages (except vertico) and have not had any issues
- da39a3ee 5y ago
  brew install emacs-plus@28 --with-native-comp might be a more standard "easy" approach on MacOS.
  - da39a3ee 5y ago
    TBH the emacs-plus install didn't work for me (the Emacs.app produced failed with `LSOpenURLsWithRole failed`), whereas build-emacs-for-macos did work.
  - kkylin 5y ago
    I suppose brew tap d12frosted/emacs-plus first? (I haven't tried it yet, and not sure I will.)
jfim 5y ago
Is the speedup during editing or does it also improve startup time?
- TacticalCoder 5y ago
  > Is the speedup during editing or does it also improve startup time? During editing/usage for sure: it is noticeable. Not that it was slow before but nearly everything now feels really snappy. As for startup I don't know as I rarely relaunch it but I just tried (only for the native-comp branch): time emacs -Q -eval '(kill-emacs)' gives 160 ms. Or launching Emacs with -Q and then calling emacs-init-time gives basically the same (-Q bypasses the config files). Starting with my entire config which is quite beefy takes 1.2s. I could probably speed it up but haven't really looked into optimizing Emacs startup in a while.
  - darthrupert 5y ago
    Emacs has been pretty slow in editing, ever since Visual Code came along to set the bar higher. Good thing that Emacs is back in the game though, that editor has heart.
    - deleted 5y ago
      [deleted]
    - geokon 5y ago
      last I tried VSCode there was a noticeable input lag (keystroke to character on screen). Is there some trick to fix this? I found it incredibly distracting. In Emacs... Magit is instantaneous while orgmode tangle/export is embarrassingly slow - but never a dealbreaker anecdotally eshell has some of the lowest latencies as well https://danluu.com/term-latency/ https://danluu.com/term-latency/
      - andai 5y ago
        I switched back from VSCode to Sublime Text (despite enjoying Intellisense) due to how much more responsive the scrolling is in Sublime.
jlarocco 5y ago
Eh, I don't know... I suspect the speed up depends a lot on how a person uses Emacs. I've been using it for a few months as well, and I haven't noticed any change. My start up time, as measured with 'emacs-init-time, is 0.6-0.7 seconds instead of 0.7-0.8, but that's about all I've noticed, and there hasn't been any difference in day-to-day editting. I haven't had any problems, so that's good at least.
- TeMPOraL 5y ago
  Definitely. Depends on how much you stuff your Emacs is running. Bare-bones Emacs was generally pretty snappy, but once you activated all the quality-of-life features and added a bunch of third-party packages, there was a noticeable performance impact. The first thing where it usually affected me was org-mode. It runs a lot of complex text-parsing and redisplay code on the buffers, and some frequently used operations (like folding/unfolding big sections of the file, or generating agenda) would noticeably slow down with files over a couple hundred lines. That problem is now mostly gone with nativecomp - probably in part because Org Mode itself is improving its performance, but in big part because all that Elisp just runs faster across the board. LSP mode would probably be another common case - but I only started using it on nativecomp and with the new JSON parsing module (Emacs 27 started supporting libjansson in place of whatever it was doing before). It works very well, but I imagine it was pretty unusable before these two changes.
  - da39a3ee 5y ago
    > but once you activated all the quality-of-life features and added a bunch of third-party packages, there was a noticeable performance impact. I'm not sure I understand what you mean there. Unless those third-party packages are scheduling tasks on the event loop then they should not be impacting performance of your other operations. Just having lots of things installed and activated doesn't affect performance.
    - cbsmith 5y ago
      It's not having lots of things installed. It's actually using them. Basically how much custom elisp is running in your buffer.
wyuenho 5y ago
It seems to still have trouble compiling code using old-style advices. By not supporting LLVM JIT, this also brings in a lot of extra dependencies on macOS, although, not as egregious as librsvg.
- rurban 5y ago
  By not supporting LLVM JIT it gains a lot of significant advantages: Small jit dependency. 1MB compared to 30MB. Fast JIT. At least 3x faster than llvm. All architectures. LLVM only supports a tiny amount of architectures, gccjit all. Only the desperate do llvm jitting.
  - wyuenho 5y ago
    Besides ARM and AMD64, what other arch do you need to support? RISC-V? I'm using MacPorts and I have no idea how to hand compile just libgccjit there. The libgcc port doesn't even produce the jit language.
    - sanxiyn 5y ago
      That's a MacPorts problem. Debian has libgccjit0 package for example. In due time, MacPorts will also package gccjit.
    - rurban 5y ago
      Google helps: https://gist.github.com/AllenDang/f019593e65572a8e0aefc96058a2d23e https://gist.github.com/AllenDang/f019593e65572a8e0aefc96058... Macports has gccjit since gcc10, just somebody needs to update Emacs. What others archs? All of course
      - wyuenho 5y ago
        Google should also help you understand that the libgcc port does not provide for libgccjit for whatever reason. I'm writing my own Portfile to get libgccjit 11 now. The emacs-devel port does bring in the entire gcc10, but I just want libgccjit.

ashton314 5y ago

I tried this on macOS a few months ago and it was pretty rocky just getting the thing compiled. I tried again last night and it pretty much Just Worked(tm) thanks to this[1] project. Note: this was on an Intel mac; anyone with an M1 tried this yet? I did run into some problems with some newer packages on the GNU ELPA. (Specifically consult, marginalia, and vertico by github.com/minad) Straight.el complained about not being able to find the packages. Any suggestions on what I might try to fix this? [1]: https://github.com/jimeh/build-emacs-for-macos https://github.com/jimeh/build-emacs-for-macos

deleted 5y ago
[deleted]
TacticalCoder 5y ago
Can't help as I'm on Linux (also I use ivy/avy/counsel and not consult/marginalia/vertico).
- dmd 5y ago
  Out of curiosity, why did you reply?
  - ashton314 5y ago
    He was replying to some questions I asked him in my reply to his top-level post. I was confused too, but now that I figured it out, I appreciate the reply.
erk__ 5y ago
Maybe try and write out the complete path for the github repo when using straight, I am using the abo e packages (except vertico) and have not had any issues
da39a3ee 5y ago
brew install emacs-plus@28 --with-native-comp might be a more standard "easy" approach on MacOS.
- da39a3ee 5y ago
  TBH the emacs-plus install didn't work for me (the Emacs.app produced failed with `LSOpenURLsWithRole failed`), whereas build-emacs-for-macos did work.
- kkylin 5y ago
  I suppose brew tap d12frosted/emacs-plus first? (I haven't tried it yet, and not sure I will.)

jfim 5y ago

Is the speedup during editing or does it also improve startup time?

TacticalCoder 5y ago
> Is the speedup during editing or does it also improve startup time? During editing/usage for sure: it is noticeable. Not that it was slow before but nearly everything now feels really snappy. As for startup I don't know as I rarely relaunch it but I just tried (only for the native-comp branch): time emacs -Q -eval '(kill-emacs)' gives 160 ms. Or launching Emacs with -Q and then calling emacs-init-time gives basically the same (-Q bypasses the config files). Starting with my entire config which is quite beefy takes 1.2s. I could probably speed it up but haven't really looked into optimizing Emacs startup in a while.
- darthrupert 5y ago
  Emacs has been pretty slow in editing, ever since Visual Code came along to set the bar higher. Good thing that Emacs is back in the game though, that editor has heart.
  - deleted 5y ago
    [deleted]
  - geokon 5y ago
    last I tried VSCode there was a noticeable input lag (keystroke to character on screen). Is there some trick to fix this? I found it incredibly distracting. In Emacs... Magit is instantaneous while orgmode tangle/export is embarrassingly slow - but never a dealbreaker anecdotally eshell has some of the lowest latencies as well https://danluu.com/term-latency/ https://danluu.com/term-latency/
    - andai 5y ago
      I switched back from VSCode to Sublime Text (despite enjoying Intellisense) due to how much more responsive the scrolling is in Sublime.

jlarocco 5y ago

Eh, I don't know... I suspect the speed up depends a lot on how a person uses Emacs. I've been using it for a few months as well, and I haven't noticed any change. My start up time, as measured with 'emacs-init-time, is 0.6-0.7 seconds instead of 0.7-0.8, but that's about all I've noticed, and there hasn't been any difference in day-to-day editting. I haven't had any problems, so that's good at least.

TeMPOraL 5y ago
Definitely. Depends on how much you stuff your Emacs is running. Bare-bones Emacs was generally pretty snappy, but once you activated all the quality-of-life features and added a bunch of third-party packages, there was a noticeable performance impact. The first thing where it usually affected me was org-mode. It runs a lot of complex text-parsing and redisplay code on the buffers, and some frequently used operations (like folding/unfolding big sections of the file, or generating agenda) would noticeably slow down with files over a couple hundred lines. That problem is now mostly gone with nativecomp - probably in part because Org Mode itself is improving its performance, but in big part because all that Elisp just runs faster across the board. LSP mode would probably be another common case - but I only started using it on nativecomp and with the new JSON parsing module (Emacs 27 started supporting libjansson in place of whatever it was doing before). It works very well, but I imagine it was pretty unusable before these two changes.
- da39a3ee 5y ago
  > but once you activated all the quality-of-life features and added a bunch of third-party packages, there was a noticeable performance impact. I'm not sure I understand what you mean there. Unless those third-party packages are scheduling tasks on the event loop then they should not be impacting performance of your other operations. Just having lots of things installed and activated doesn't affect performance.
  - cbsmith 5y ago
    It's not having lots of things installed. It's actually using them. Basically how much custom elisp is running in your buffer.

wyuenho 5y ago

It seems to still have trouble compiling code using old-style advices. By not supporting LLVM JIT, this also brings in a lot of extra dependencies on macOS, although, not as egregious as librsvg.

rurban 5y ago
By not supporting LLVM JIT it gains a lot of significant advantages: Small jit dependency. 1MB compared to 30MB. Fast JIT. At least 3x faster than llvm. All architectures. LLVM only supports a tiny amount of architectures, gccjit all. Only the desperate do llvm jitting.
- wyuenho 5y ago
  Besides ARM and AMD64, what other arch do you need to support? RISC-V? I'm using MacPorts and I have no idea how to hand compile just libgccjit there. The libgcc port doesn't even produce the jit language.
  - sanxiyn 5y ago
    That's a MacPorts problem. Debian has libgccjit0 package for example. In due time, MacPorts will also package gccjit.
  - rurban 5y ago
    Google helps: https://gist.github.com/AllenDang/f019593e65572a8e0aefc96058a2d23e https://gist.github.com/AllenDang/f019593e65572a8e0aefc96058... Macports has gccjit since gcc10, just somebody needs to update Emacs. What others archs? All of course
    - wyuenho 5y ago
      Google should also help you understand that the libgcc port does not provide for libgccjit for whatever reason. I'm writing my own Portfile to get libgccjit 11 now. The emacs-devel port does bring in the entire gcc10, but I just want libgccjit.