Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bringing GNU Emacs to Native Code (2020)

arxiv.org

Post reply on HN
Print view View original

21–30 of 138 posts

Re: Bringing GNU Emacs to Native Code (2020)

#21

Post by TacticalCoder »

jfim wrote: post #8
TacticalCoder wrote: post #2

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 The only drawback I saw is that compiling Emacs itself takes 3x to 4x longer when compiling the native-comp branch.

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

> 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.

Re: Bringing GNU Emacs to Native Code (2020)

#24

Post by TacticalCoder »

ashton314 wrote: post #4
TacticalCoder wrote: post #2

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 The only drawback I saw is that compiling Emacs itself takes 3x to 4x longer when compiling the native-comp branch.

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…

Can't help as I'm on Linux (also I use ivy/avy/counsel and not consult/marginalia/vertico).

Re: Bringing GNU Emacs to Native Code (2020)

#25

Post by darthrupert »

TacticalCoder wrote: post #21
jfim wrote: post #8

Earlier quoted context omitted.

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

> 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 basical…

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.

Re: Bringing GNU Emacs to Native Code (2020)

#26

Post by jlarocco »

TacticalCoder wrote: post #2

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 The only drawback I saw is that compiling Emacs itself takes 3x to 4x longer when compiling the native-comp branch.

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.

Re: Bringing GNU Emacs to Native Code (2020)

#27

Post by wyuenho »

TacticalCoder wrote: post #2

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 The only drawback I saw is that compiling Emacs itself takes 3x to 4x longer when compiling the native-comp branch.

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.

Re: Bringing GNU Emacs to Native Code (2020)

#28

Post by erk__ »

ashton314 wrote: post #4
TacticalCoder wrote: post #2

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 The only drawback I saw is that compiling Emacs itself takes 3x to 4x longer when compiling the native-comp branch.

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…

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
Post reply on HN