I am curious how many of you are using native compilation.

Native compilation has been out for some years, and the performance boost from it for old machines is night and day, e.g. my old macbook. However, with the beefy hardware of the new machines, e.g. M1 mac, the effect of native compilation becomes indistinguishable. On my Linux desktop, which was built in 2019, I have been using native compilation since the beginning, but I just freshly compiled from source without native compilation and found no obvious performance difference at all. And on my new macbook with M1Pro, the performance is similar, and no obvious power consumption difference. Without performance differences, the only thing native compilation brings is the large usage in disk space, although in today's standard, the disk space used by native compilation is far from being significant. I am curious how many people are using native compilation right now. What machine you are on and why? [View Poll](https://www.reddit.com/poll/uv49ix)

I cannot feel the advantage of native comp on macOS 12 MBP 2019, it even slows down my emacs startup time for 1 second.

I run on laptops and servers from the last few years. I regularly use mu4e, projectile, magit and have found no perceivable difference.

On modern hardware, without native I would encounter micro-stutters here and there, and most frequently while smooth scrolling using [good-scroll](https://github.com/io12/good-scroll.el). Stuttering is non-existent for me on native, so I'm definitely enjoying that. And also less empirically, just general command execution feels a bit more snappy. Though, I've an acute sense of responsiveness as I used to be into competitive csgo, and would care about getting higher than 300fps even on a 144hz refresh rate monitor in order to reduce the chance of getting old frames being drawn onto the screen, and just by moving the mouse you could tell if the frame-rate was sub-par.

I’ve been using native comp on macOS since around June 2020. At the time it made a world of a difference to the performance of Emacs for me. At that point performance had slowly been starting to annoy me for a couple of years, to the point I had started considering if I should try and switch to VSCode. The native json parsing support added in Emacs 27.x in early 2020 had definitely improved performance with lsp-mode, but overall I still had issues. Native comp however solved all of that. All stutters, lags, and slowdowns were just gone, and Emacs' performance actually felt on par if not better than VSCode. That was the summer of 2020. I’m still using native comp builds on macOS, now with Emacs 29.x nightly builds. I did briefly test a build without native comp around the end of last year, and the difference was no where near as drastic as it used to be. But it was still noticeable, especially when triggering commands or causing UI rendering changes. Though my own config had received a lot improvements since I first started using native comp, and my understanding is that Emacs itself had also received a number of performance improvements and fixes unrelated to native comp.

What about linux and windows with native compilation as option?

Feels a little faster, but honestly clearing the warnings window that frequently pops up on startup probably makes it a wash

I don't use it, as I don't notice the performance improvements it's providing, but I do notice the hit when it needs to recompile things (although a brief test with the 28.1 release suggested that compilation times had been improved since I'd last tried it, so I may yet experiment more). Also my start times are faster without it (and [much, much faster](https://old.reddit.com/r/emacs/comments/sed9oy/native_compilation_vs_virus_scanners/) in the presence of a virus scanner).

That shouldn't be the case, I'd be interested to know what actually causes that. Do you mean that you haven't let the compilation finish yet? If that's the case that shouldn't alter your startup time but you could notice a more *busy* Emacs instance at times until it finishes up Edit: I see another comment reporting the same thing. That surprises me much (I don't have the issue at all)

There's no option for it but I use it daily on both MacOs and Debian

It would be a hell of a shame if a feature that substantially complicates downstream packaging of Emacs turns out to produce unnoticeable performance changes.

Exactly the same situation here. My (totally baseless) theory is that since emacs is a weird app it encounters a bunch of slow-downs on macOS. Though native may make the code run faster I feel it introduces more blocks as more permissions are needed... Let me know if this is stupid.

I always use native comp now. Windows, Linux (incl WSL2) and Mac.

>Do you mean that you haven't let the compilation finish yet? The compilation is already done, I tired native comp for several weeks. I'm using emacs-mac, maybe that is the reason(or one of the reasons).

I'm currently waiting for all my packages to build on Guix before updating Emacs to 28.1 🥲. Anyhow, I don't know if I'll be using native-comp before it is supported on the official Guix channel, which should take some time.

The virtual machines provided at $JOB are woefully underpowered. Granted, we are supposed to submit real work to the compute farm, but emacs alone puts a stress on the interactive VM. Native compile helps tremendously and makes emacs far more responsive.

I've being using it since Andrea has announced it and posted first working version :).

Those warnings can be disabled by setting: `(setq native-comp-async-report-warnings-errors nil)` in your configuration file.

Somewhat related, I have a benchmark for native-comp via an ARM binary vs x86-64 binary on the M1: [https://github.com/enzuru/native-comp-elisp-benchmarks/blob/master/cpu/apple-m1.org](https://github.com/enzuru/native-comp-elisp-benchmarks/blob/master/cpu/apple-m1.org) You can use the \`elisp-benchmarks\` package to produce results like these. As for native comp vs regular comp, I have noticed a bigger difference on Linux and a smaller difference on macOS.

I have no idea what I'm using.

That's good to know. Thanks!

Is there a how to native compilación for macOS?

both macos and freebsd with native comp

Now a days it’s mostly just a matter of installing `gcc` and `libgccjit` Homebrew formulas, and then setting the relevant configure flags. For my own purposes I maintain a [build script](https://github.com/jimeh/build-emacs-for-macos) and [binary builds](https://github.com/jimeh/emacs-builds) project, allowing me to install the latest nightly as a Homebrew cask. And there’s also the excellent [emacs-plus](https://github.com/d12frosted/homebrew-emacs-plus) homebrew formula.

Mac with native comp selected Also linux, freebsd with native comp Old windows package without native comp because I don’t use that one much

Make sure that native comp really works on your machine. For me it works great! Excellent innovation :-)

Lots of people report very noticeable performance changes, and I suspect there's scope for future optimisations to native code as well. It's just a YMMV situation, depending on many variables.

[deleted]

[deleted]

Didn't seem to be faster and disabled.

Observed random pause on macOs with native comp

I think it's natural that it would affect load times. With the addition of `.eln` files into the mixture, Emacs has *more* things to look at then it did before; and in order to find the right `.eln` file it needs to do some hashing of various identifying metadata, and compare that with the hash in the filename; and with the `.eln` files being much bigger, there might be some filesystem I/O differences for reading in those files as well. I suspect the question is more "is it possible to do all those things quickly enough that the extra work goes unnoticed", and that might be a YMMV; but multiplied by the number of libraries a user ends up loading when they start Emacs, it seems that it's easy enough for the slow-down to become apparent. The native-compilation feature is all about getting *run-time* performance improvements, so I think some hits at load-time are just one of the trade-offs being made to achieve that.

native comp. seems to have made a huge difference with the Emacs scrolling problem using the touch pad on macOS. So what used to be *very* annoying is now bearable - compared to the smoothness of eg Safari and Word. Still, as I haven't made any tests, the improvement could also be due to other enhancements... I'm on a MacBook Pro M1 Pro.

So what you are saying is elisp performance does not matter because all the work is done by functions in the c core? I highly doubt that …

If you are talking about scrolling experience on macOS, the emacs macport is second to none.

Uff i had the same issue, it took about 24 hours for Guix to build all my packages before I could get 28.1! I think the solution is to use manifests liberally. I was advised to set up a core manifest for emacs, guile, lightweight and stable programmes. Then another for eyecandy. Then individual manifests for heavy or unstable packages like Blender, Firefox, OpenOffice, Gimp, etc. Then when you want to upgrade you can `guix weather $manifest` to test availability, or upgrade each manifest and then just cancel the ones which take too long.

/u/7890yuiop > I do notice the hit when it needs to recompile things No idea what machine do you use. On my 2016 machine (which was though beefy when I put it together), I don't notice it all. But there is an option to compile eln files ahead of time, that might be useful to you? > Also my start times are faster without it Interesting, when I run emacs -Q on my computer with or without native comp, I see no difference. > (and much, much faster in the presence of a virus scanner). Most virus scanners give you an option to exclude files and directories from the scan. It might be useful to put eln-cache directory into that list.

Can you point us to some benchmarks that make sense than?

Was probably a MacOS specfic problem. On Linux too, native JSON helped a lot of eglot (another LSP thingy). But for my workload (mostly programming), native compilation doesn't make terrible difference. I didn't notice lags or stutters before, at all. Sure, Ivy felt faster than Helm, but even that only marginally.

Yeah, that’s very possible. The macOS GUI implementation in Emacs has seen quite a lot love in the last few years, and a number of performance improvements to Emacs in general have also landed in the master branch recently. All in all my nightly builds of 29.x from master are snappier than ever :)

This is totally weird. 24 hours seems broken. When I compile Emacs from GIT on Debian Stable (with a freshly cloned git tree), I get these times: * `./configure` step: 36.6 seconds real-time * `make -j6` (I actually have 8 cores, but often I only use only 6 to not drag my other tasks down too much): **10.8 minutes** real-time All times from today, branch master, HEAD pointing to f437ddf2e9d8b0e6e04d639343c717a0096f1090. So you see, native compilation from scratch (like a reproducible build system does) isn't certainly very fast, but it isn't also as terribly slow as you described. For the record, the configure I used is (partly done by my, partly taken from what the Debian compilation rules file declared): ./configure \ -C \ --with-cairo \ --with-dbus \ --with-gnutls \ --with-gpm=no \ --with-imagemagick \ --with-json \ --with-modules \ --with-native-compilation \ --with-pgtk \ --with-rsvg \ --with-toolkit-scroll-bars \ --with-x-toolkit=gtk3 \ --with-xml2 \ --with-xwidgets \ --without-gconf \ --without-gpm \ --without-gsettings \ --without-hesiod \ --without-imagemagick \ --without-kerberos \ --without-kerberos5 \ --without-ns \ --without-pop \ --without-selinux \ --without-wide-int \ --without-xim \ CFLAGS='-g -O2 -march=native -ffile-prefix-map=/home/holger=. -fstack-protector-strong -Wformat -Werror=format-security -Wall -fno-omit-frame-pointer' CPPFLAGS='-Wdate-time -D_FORTIFY_SOURCE=2' \ LDFLAGS='-Wl,-z,relro' (Oh, and I just notice that I should perhaps remove the experimental `--with-pgtk` switch ...)

I am and emacs-mac is definitely the best Emacs on macOS. By far. Still, it (until recently) scrolled like a stuttering turtle 😉

Thank you for this link! I have just PR'd my 5900x benchmark of Emacs 29 which is substantially faster than the previous Emacs 28 benchmark on another 5900x system. PR: https://github.com/enzuru/native-comp-elisp-benchmarks/pull/7 Although I have been running and appreciating native-comp for more than two years now, I have also recently become more curious about its real-world impact, which is not straight-forward to measure.