19 ms·

Bringing GNU Emacs to Native Code (2020)

369 points by textread 5y ago

deleted 5y ago
[deleted]
TacticalCoder 5y ago
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.
deleted 5y ago
[deleted]
DDSDev 5y ago
I think that nativecomp represents a huge leap forward for emacs. I continually give kudos to Andrea Corallo and the entire team for making this a possibility. I think that the next major leap for emacs needs to involve the garbage collector and allocation logic. I think that a large class of performance optimizations would be possible with an improved GC, including improvements to emacs existing threading capabilities.
- fiddlerwoaroof 5y ago
  My impression is that the major bottleneck is the redisplay loop.
- volta83 5y ago
  I think nativcomp doesn't really improve what makes emacs "slow". Emacs is a single threaded synchronous and blocking UI system. Sometimes when my autocomplete, C++ checking, git checking, auto formating, ... run, the editor freezes, for multiple seconds. All this stuff runs in the UI thread. Braindamaged. The other thing that makes emacs slow is remote editing. Emacs TRAMP uses one ssh connection per command. VS Code spawns a remote server and asynchronously updates the remote's state. VS Code remote editing experience is as good as the local one, but emacs experience is supper laggy, recurrent freezes of multiple seconds, etc. Particularly when navigating the filesystem in the remote in any modern emacs way (helm, ido, etc.). Or when auto-save happens and everything blocks for multiple seconds, etc. --- I don't really care if native compilation makes single threaded code faster, if that single threaded code runs in the UI thread and blocks the editor for 10 seconds. Sure now it maybe blocks for 9 seconds, because you can't do much about those 9 seconds you have to wait for some IO operation to complete. But that still sucks.
  - cjohansson 5y ago
    I agree about this issue, maybe in the distant future this could be fixed as well but where will VSCode be at that stage? Probably even more miles ahead, due to MS funding. When there is good async support in Emacs a lot of packages would need to be rewritten. However I prefer Emacs anyday over VSCode, I am very productive in Emacs because I'm used to doing almost everything in it
dreamcompiler 5y ago
Slime didn't work for me in this version of Emacs. (Slime is the Common Lisp IDE for Emacs). I don't remember the details but I think Slime was getting confused about .el vs .elc files and assuming there was no third option, but now there is.
- fiddlerwoaroof 5y ago
  Interesting, I've been using Slime with nativecomp for a long time.
  - dreamcompiler 5y ago
    Wow. Guess I need to try again.
mark_l_watson 5y ago
I am excited by this. I tried it a few months ago, then switched to a M1 Mac and went back to a current stable version. I find IDEs that are M1 native are noticeably faster. I look forward to a M1 native libgccjit Emacs.
rcakebread 5y ago
Getting much better fps in Doom in Emacs now.
- 40four 5y ago
  This is my favorite comment of the day! Kudos :) I don’t care if it gets downvoted by guidelines lawyers
  - deleted 5y ago
    [deleted]
- zeofig 5y ago
  Is there a Doom module for this?
  - rcakebread 5y ago
    It was a joke. Until you asked this.
  - drran 5y ago
    He's talking about Doom Emacs: https://github.com/hlissner/doom-emacs https://github.com/hlissner/doom-emacs
  - codesuki 5y ago
    https://www.reddit.com/r/emacs/comments/f2c99b/you_can_play_doom_inside_emacs_using_eaf/ https://www.reddit.com/r/emacs/comments/f2c99b/you_can_play_...
yewenjie 5y ago
I have really liked native-comp so far on Arch Linux. I think in the last year or so I have had total two hiccups only due to nativ-comp.
- girzel 5y ago
  The requisite libgccjit AUR package was broken for a bit, fixed just a day or so ago.
the_duke 5y ago
Every time I try Emacs I get annoyed by it's slowness and go back to vim and VS Code. This might entice me to build it and try out my Emacs Doom setup again.
- nXqd 5y ago
  hell yeah me too, this will make it get back to Emacs again :D
- tejuis 5y ago
  There are number of things you can do to improve your situation. Obviously you should not have packages loaded that you don't rely use. There are also ways to perform "lazy" loading, so that memory image is minimal until a package is really needed. I'm not using this myself. My usage model is such that I only start one Emacs and use emacsclient to add files for editing from terminals. Emacs is running all the time (weeks/months). Since Emacs is my primary interface to my Linux box, I give it some priviledges. In the .xsession I do: vmtouch -t $HOME/.emacs.d; vmtouch -ld /usr/bin/emacs-gtk Which effectively ensures that critical Emacs images and data is present in the memory all the time. Check out vmtouch utility. It might be useful for other purposes as well.
  - the_duke 5y ago
    My problem is really not the startup/loading time, but the regular stutters and long latency for input and commands. I need my editor to "feel" really smooth and instant during editing. Emacs just never gives me that experience. I think many long-time Emacs (and Jetbrains IDEs, for that matter) users just don't notice how laggy it is because they are so used to it, or are not very latency sensitive.
    - LanternLight83 5y ago
      As a vim user who's transitioned to Emacs with evil, response latency just feels so much better in vim, and although I love and use the daemon-client tip, it misses that point.
- 5y ago
pixel_fcker 5y ago
It makes LSPs usable for me on my desktop 5950x. Still a bit laggy on my laptop.
- samus 5y ago
  Unfortunately, Emacs won't really benefit since it is a (mostly) single-threaded application by design. But that sweet 5950x should definitely speed up running dozens of language servers and indexers at the same time :-D
  - pixel_fcker 5y ago
    Yes it’s a shame. I really like emacs but the lagginess is just too jarring while working.
elongatedMusku 5y ago
I'm really excited and grateful. Thank you!
rubyn00bie 5y ago
I'm 100% not trolling with this question, I really like Emacs, buuut: Does it fix having to restart Emacs after at most 8-16 hours of use? Could this experience be a plugin I use, or my own idiocy? Originally, I assumed "YES! Of course! I am idiot... This is my fault!" Then came the observation when pairing with people (across a variety of languages) who use Emacs, who all say on a regular basis, without so much as a thought to it: "one sec, I just need to restart Emacs." Followed by 30 seconds of restarting Emacs and 30 more seconds setting up the buffers. I'd definitely use Emacs but the inevitable, and uncontrollable, lockups kill it for me.
- ashton314 5y ago
  I'd bet it's just your setup. I had one Emacs session run for almost a month straight—and that was with LSP mode running on a fairly large Elixir project. I only restarted it because I needed to restart the machine I was running it on. It was using barely over 300 MB of RAM. (Lots and lots of open buffers and whatnot.) That's not an unusual occurrence for me—and I'm not even running the native-comp branch yet! FWIW, my Emacs init time (run `emacs-init-time`) is between 2–7 seconds, and I'm not doing anything particularly special to get that working. I'd start out with a fresh .emacs config file and then add the packages you want with the excellent `use-package` macro, setting `:defer t` as much as possible. (Often this will be implicit if you have `:mode`, `:hook`, or `:bind` configured, if I'm not mistaken.) It would be better if Emacs were less sensitive to how your config is setup, but alas, we live in a fallen world. You can also ask around on r/emacs and get some better tips than mine.
  - kfajdsl 5y ago
    I basic used `:defer t` for a while (Doom Emacs lazy loaded under the hood), but when I switched to my own config I decided to just run it in daemon mode and use `:demand t` on everything. I didn't like pauses sometimes when opening a new file while it loaded a package. Actually, I just checked my init time with that command, and it's ~2.5 seconds. I wouldn't call my config heavyweight, but it does have evil, lsp, vterm, ivy, magic, etc. I am using the native-comp branch though.
- 5y ago
aome510 5y ago
Really hope to see Emacs get more attention after `native-comp` branch merged to master. Recently, I have switched to Emacs full-time (first spacemacs[0], now doom[1]). So far, it has been a great experience. Spacemacs is a bit slow but with doom and `native-comp`, I rarely encounter any performance issues. [0]: https://github.com/syl20bnr/spacemacs https://github.com/syl20bnr/spacemacs [1]: https://github.com/hlissner/doom-emacs https://github.com/hlissner/doom-emacs
- yewenjie 5y ago
  I love Doom but it needs more documentation and more developers/maintainers. If your Elisp is good and you use Doom I would strongly recommend contributing to the code. Even if your Elisp is not good, you can totally contribute towards documentation.
dang 5y ago
One related thread from last year: Bringing GNU Emacs to native code [video] - https://news.ycombinator.com/item?id=23066971 https://news.ycombinator.com/item?id=23066971 - May 2020 (83 comments)
harles 5y ago
Genuine question: why is this on Arxiv? It seems like a design document in the format of a research paper.
- rurban 5y ago
  It's the submission paper to the 13th European Lisp Symposium (ELS20) last year in Zurich. Lisp conferences put a higher demand on their submissions to be like formal papers. With external reviewers and such. This is one. At this stage nativecomp was not yet finished, see his webpage for the progress. Expect another paper for the final evaluation of the improvements. It has big impact on programming languages implementations, esp. compared to llvm. It's the very first big gccjit project, and a huge success.
- marco_craveiro 5y ago
  Experience reports are also common as scientific papers. [1] [1] https://sigdoc.acm.org/conference/2017/guidelines-experience-reports/ https://sigdoc.acm.org/conference/2017/guidelines-experience...
- da39a3ee 5y ago
  Your question comes across as uncharitable and I suspect you have no relevant experience. Without implying that your question has any validity, if you have an academic career, you need publications. Therefore it's the opposite of what you imply. We want people to feel welcome to write up all sorts of computing achievements in academic forums, because that is what will help the authors be able to carry on doing what they are doing and thus allow us to benefit from their work.
siraben 5y ago
gccemacs is amazing! I've been using for more than a year on macOS and NixOS, and it's been superb (though from time to time I clear downloaded packages and the native cache just in case). It's definitely an impressive feat of engineering as well. If you haven't seen the developer's website on it[0], you should definitely check it out. For Nix users on macOS, see[1]. Here's how I used it in my home-manager config[2]. For Nix users on Linux and NixOS, see the Emacs overlay[3]. There's even Emacs nativecomp + wayland support (emacsPgtkGcc) there. [0] https://akrl.sdf.org/gccemacs.html https://akrl.sdf.org/gccemacs.html [1] https://github.com/twlz0ne/nix-gccemacs-darwin https://github.com/twlz0ne/nix-gccemacs-darwin [2] https://github.com/siraben/dotfiles/blob/8161e1b72965b48f8223fd4624554ebae20d7ce4/home-manager/.config/nixpkgs/home.nix#L23 https://github.com/siraben/dotfiles/blob/8161e1b72965b48f822... [3] https://github.com/nix-community/emacs-overlay https://github.com/nix-community/emacs-overlay
Rochus 5y ago
Here is a stream of the corresponding lecture at the European Lisp Symposium 2020: https://www.youtube.com/watch?v=zKHYZOAc_bQ https://www.youtube.com/watch?v=zKHYZOAc_bQ And here are the slides: https://www.european-lisp-symposium.org/static/2020/corallo-nassi-manca-slides.pdf https://www.european-lisp-symposium.org/static/2020/corallo-...
vcdimension 5y ago
Has anyone tried this with gnus? Is it noticeably faster?
da39a3ee 5y ago
Given an installed emacs, what's the best way to check whether it was built with this feature and that the feature is active?
- rgrau 5y ago
  Several ways (overkill answer, but leaving all options I know because why not): You can try evaluating this in the scratch buffer (if (member 'nativecomp features) (message "yay") (message "nay")) Or check if a non-interactive function called `native-compile` exists. Or open help for an elisp function (next-line, for example): c-h f next-line RET Gives me: next-line is an interactive native compiled Lisp function in ‘simple.el’. Or, m-x disassemble next-line RET

369 points by textread 5y ago

deleted 5y ago

[deleted]

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.

deleted 5y ago

[deleted]

DDSDev 5y ago

I think that nativecomp represents a huge leap forward for emacs. I continually give kudos to Andrea Corallo and the entire team for making this a possibility. I think that the next major leap for emacs needs to involve the garbage collector and allocation logic. I think that a large class of performance optimizations would be possible with an improved GC, including improvements to emacs existing threading capabilities.

fiddlerwoaroof 5y ago
My impression is that the major bottleneck is the redisplay loop.
volta83 5y ago
I think nativcomp doesn't really improve what makes emacs "slow". Emacs is a single threaded synchronous and blocking UI system. Sometimes when my autocomplete, C++ checking, git checking, auto formating, ... run, the editor freezes, for multiple seconds. All this stuff runs in the UI thread. Braindamaged. The other thing that makes emacs slow is remote editing. Emacs TRAMP uses one ssh connection per command. VS Code spawns a remote server and asynchronously updates the remote's state. VS Code remote editing experience is as good as the local one, but emacs experience is supper laggy, recurrent freezes of multiple seconds, etc. Particularly when navigating the filesystem in the remote in any modern emacs way (helm, ido, etc.). Or when auto-save happens and everything blocks for multiple seconds, etc. --- I don't really care if native compilation makes single threaded code faster, if that single threaded code runs in the UI thread and blocks the editor for 10 seconds. Sure now it maybe blocks for 9 seconds, because you can't do much about those 9 seconds you have to wait for some IO operation to complete. But that still sucks.
- cjohansson 5y ago
  I agree about this issue, maybe in the distant future this could be fixed as well but where will VSCode be at that stage? Probably even more miles ahead, due to MS funding. When there is good async support in Emacs a lot of packages would need to be rewritten. However I prefer Emacs anyday over VSCode, I am very productive in Emacs because I'm used to doing almost everything in it

dreamcompiler 5y ago

Slime didn't work for me in this version of Emacs. (Slime is the Common Lisp IDE for Emacs). I don't remember the details but I think Slime was getting confused about .el vs .elc files and assuming there was no third option, but now there is.

fiddlerwoaroof 5y ago
Interesting, I've been using Slime with nativecomp for a long time.
- dreamcompiler 5y ago
  Wow. Guess I need to try again.

mark_l_watson 5y ago

I am excited by this. I tried it a few months ago, then switched to a M1 Mac and went back to a current stable version. I find IDEs that are M1 native are noticeably faster. I look forward to a M1 native libgccjit Emacs.

rcakebread 5y ago

Getting much better fps in Doom in Emacs now.

40four 5y ago
This is my favorite comment of the day! Kudos :) I don’t care if it gets downvoted by guidelines lawyers
- deleted 5y ago
  [deleted]
zeofig 5y ago
Is there a Doom module for this?
- rcakebread 5y ago
  It was a joke. Until you asked this.
- drran 5y ago
  He's talking about Doom Emacs: https://github.com/hlissner/doom-emacs https://github.com/hlissner/doom-emacs
- codesuki 5y ago
  https://www.reddit.com/r/emacs/comments/f2c99b/you_can_play_doom_inside_emacs_using_eaf/ https://www.reddit.com/r/emacs/comments/f2c99b/you_can_play_...

yewenjie 5y ago

I have really liked native-comp so far on Arch Linux. I think in the last year or so I have had total two hiccups only due to nativ-comp.

girzel 5y ago
The requisite libgccjit AUR package was broken for a bit, fixed just a day or so ago.

the_duke 5y ago

Every time I try Emacs I get annoyed by it's slowness and go back to vim and VS Code. This might entice me to build it and try out my Emacs Doom setup again.

nXqd 5y ago
hell yeah me too, this will make it get back to Emacs again :D
tejuis 5y ago
There are number of things you can do to improve your situation. Obviously you should not have packages loaded that you don't rely use. There are also ways to perform "lazy" loading, so that memory image is minimal until a package is really needed. I'm not using this myself. My usage model is such that I only start one Emacs and use emacsclient to add files for editing from terminals. Emacs is running all the time (weeks/months). Since Emacs is my primary interface to my Linux box, I give it some priviledges. In the .xsession I do: vmtouch -t $HOME/.emacs.d; vmtouch -ld /usr/bin/emacs-gtk Which effectively ensures that critical Emacs images and data is present in the memory all the time. Check out vmtouch utility. It might be useful for other purposes as well.
- the_duke 5y ago
  My problem is really not the startup/loading time, but the regular stutters and long latency for input and commands. I need my editor to "feel" really smooth and instant during editing. Emacs just never gives me that experience. I think many long-time Emacs (and Jetbrains IDEs, for that matter) users just don't notice how laggy it is because they are so used to it, or are not very latency sensitive.
  - LanternLight83 5y ago
    As a vim user who's transitioned to Emacs with evil, response latency just feels so much better in vim, and although I love and use the daemon-client tip, it misses that point.
5y ago

pixel_fcker 5y ago

It makes LSPs usable for me on my desktop 5950x. Still a bit laggy on my laptop.

samus 5y ago
Unfortunately, Emacs won't really benefit since it is a (mostly) single-threaded application by design. But that sweet 5950x should definitely speed up running dozens of language servers and indexers at the same time :-D
- pixel_fcker 5y ago
  Yes it’s a shame. I really like emacs but the lagginess is just too jarring while working.

elongatedMusku 5y ago

I'm really excited and grateful. Thank you!

rubyn00bie 5y ago

I'm 100% not trolling with this question, I really like Emacs, buuut: Does it fix having to restart Emacs after at most 8-16 hours of use? Could this experience be a plugin I use, or my own idiocy? Originally, I assumed "YES! Of course! I am idiot... This is my fault!" Then came the observation when pairing with people (across a variety of languages) who use Emacs, who all say on a regular basis, without so much as a thought to it: "one sec, I just need to restart Emacs." Followed by 30 seconds of restarting Emacs and 30 more seconds setting up the buffers. I'd definitely use Emacs but the inevitable, and uncontrollable, lockups kill it for me.

ashton314 5y ago
I'd bet it's just your setup. I had one Emacs session run for almost a month straight—and that was with LSP mode running on a fairly large Elixir project. I only restarted it because I needed to restart the machine I was running it on. It was using barely over 300 MB of RAM. (Lots and lots of open buffers and whatnot.) That's not an unusual occurrence for me—and I'm not even running the native-comp branch yet! FWIW, my Emacs init time (run `emacs-init-time`) is between 2–7 seconds, and I'm not doing anything particularly special to get that working. I'd start out with a fresh .emacs config file and then add the packages you want with the excellent `use-package` macro, setting `:defer t` as much as possible. (Often this will be implicit if you have `:mode`, `:hook`, or `:bind` configured, if I'm not mistaken.) It would be better if Emacs were less sensitive to how your config is setup, but alas, we live in a fallen world. You can also ask around on r/emacs and get some better tips than mine.
- kfajdsl 5y ago
  I basic used `:defer t` for a while (Doom Emacs lazy loaded under the hood), but when I switched to my own config I decided to just run it in daemon mode and use `:demand t` on everything. I didn't like pauses sometimes when opening a new file while it loaded a package. Actually, I just checked my init time with that command, and it's ~2.5 seconds. I wouldn't call my config heavyweight, but it does have evil, lsp, vterm, ivy, magic, etc. I am using the native-comp branch though.
5y ago

aome510 5y ago

Really hope to see Emacs get more attention after `native-comp` branch merged to master. Recently, I have switched to Emacs full-time (first spacemacs[0], now doom[1]). So far, it has been a great experience. Spacemacs is a bit slow but with doom and `native-comp`, I rarely encounter any performance issues. [0]: https://github.com/syl20bnr/spacemacs https://github.com/syl20bnr/spacemacs [1]: https://github.com/hlissner/doom-emacs https://github.com/hlissner/doom-emacs

yewenjie 5y ago
I love Doom but it needs more documentation and more developers/maintainers. If your Elisp is good and you use Doom I would strongly recommend contributing to the code. Even if your Elisp is not good, you can totally contribute towards documentation.

dang 5y ago

One related thread from last year: Bringing GNU Emacs to native code [video] - https://news.ycombinator.com/item?id=23066971 https://news.ycombinator.com/item?id=23066971 - May 2020 (83 comments)

harles 5y ago

Genuine question: why is this on Arxiv? It seems like a design document in the format of a research paper.

rurban 5y ago
It's the submission paper to the 13th European Lisp Symposium (ELS20) last year in Zurich. Lisp conferences put a higher demand on their submissions to be like formal papers. With external reviewers and such. This is one. At this stage nativecomp was not yet finished, see his webpage for the progress. Expect another paper for the final evaluation of the improvements. It has big impact on programming languages implementations, esp. compared to llvm. It's the very first big gccjit project, and a huge success.
marco_craveiro 5y ago
Experience reports are also common as scientific papers. [1] [1] https://sigdoc.acm.org/conference/2017/guidelines-experience-reports/ https://sigdoc.acm.org/conference/2017/guidelines-experience...
da39a3ee 5y ago
Your question comes across as uncharitable and I suspect you have no relevant experience. Without implying that your question has any validity, if you have an academic career, you need publications. Therefore it's the opposite of what you imply. We want people to feel welcome to write up all sorts of computing achievements in academic forums, because that is what will help the authors be able to carry on doing what they are doing and thus allow us to benefit from their work.

siraben 5y ago

gccemacs is amazing! I've been using for more than a year on macOS and NixOS, and it's been superb (though from time to time I clear downloaded packages and the native cache just in case). It's definitely an impressive feat of engineering as well. If you haven't seen the developer's website on it[0], you should definitely check it out. For Nix users on macOS, see[1]. Here's how I used it in my home-manager config[2]. For Nix users on Linux and NixOS, see the Emacs overlay[3]. There's even Emacs nativecomp + wayland support (emacsPgtkGcc) there. [0] https://akrl.sdf.org/gccemacs.html https://akrl.sdf.org/gccemacs.html [1] https://github.com/twlz0ne/nix-gccemacs-darwin https://github.com/twlz0ne/nix-gccemacs-darwin [2] https://github.com/siraben/dotfiles/blob/8161e1b72965b48f8223fd4624554ebae20d7ce4/home-manager/.config/nixpkgs/home.nix#L23 https://github.com/siraben/dotfiles/blob/8161e1b72965b48f822... [3] https://github.com/nix-community/emacs-overlay https://github.com/nix-community/emacs-overlay

Rochus 5y ago

Here is a stream of the corresponding lecture at the European Lisp Symposium 2020: https://www.youtube.com/watch?v=zKHYZOAc_bQ https://www.youtube.com/watch?v=zKHYZOAc_bQ And here are the slides: https://www.european-lisp-symposium.org/static/2020/corallo-nassi-manca-slides.pdf https://www.european-lisp-symposium.org/static/2020/corallo-...

vcdimension 5y ago

Has anyone tried this with gnus? Is it noticeably faster?

da39a3ee 5y ago

Given an installed emacs, what's the best way to check whether it was built with this feature and that the feature is active?

rgrau 5y ago
Several ways (overkill answer, but leaving all options I know because why not): You can try evaluating this in the scratch buffer (if (member 'nativecomp features) (message "yay") (message "nay")) Or check if a non-interactive function called `native-compile` exists. Or open help for an elisp function (next-line, for example): c-h f next-line RET Gives me: next-line is an interactive native compiled Lisp function in ‘simple.el’. Or, m-x disassemble next-line RET