It's fantastic! If you are on a mac you can try it right now with emacs-plus[1]. Emacs plus even works natively with apple m1. Doom[2] with CIDER[3] is such an incredible dev experience and I've only recently started using clojure. Native comp makea everything so snappy.

[1]https://github.com/d12frosted/homebrew-emacs-plus

[2]https://github.com/hlissner/doom-emacs

[3]https://github.com/clojure-emacs/cider

I'm torn. I do feel it makes improvements. But I also add "-O3" to my compilation. And I also feel that makes things faster. I add "-march=native" on my Linux box. Again, feels faster.

What worries me, is that most of the feeling is just placebo. I know native is faster, but by how much? Are there any good benchmarks for measuring emacs speed?

If you load a bunch of packages at startup that take several seconds to load that is as good a benchmark as any. I have this at the end of my init.el:

    (run-with-idle-timer
     3 nil
     (lambda ()
       (let ((inhibit-message t))
         (message "Emacs ready in %s with %d garbage collections."
                  (format "%.2f seconds"
                          (float-time
                           (time-subtract after-init-time before-init-time)))
                  gcs-done))))

My startup had always been under a second. On a Mac, the command to get the path right is the longest pole. Remains so in native.

That said, I'll play with it some. Still looking for a broader benchmark, though.

Edit: Looks like I lied. Startup is about 2 seconds, but is mainly dominated by a network hit to refresh packages. (So, slower if I'm on a bad network... I should fix that.) Your script, though, is odd, as I can get to the Messages buffer and wait a second before I see that message show up. (Also, you can just eval (emacs-init-time))

I'm sure I got this code from someone else, was going to replace it with (emacs-init-time) myself but I suppose it's nice to only have the first two numerals after the decimal point which this code does and (emacs-init-time) doesn't.

Funny, coming back to this, if I recompile without native compilation and any other flags, I get faster startups. By upwards of 1 second. (So, from almost 2 seconds to almost 1 second.)

An emacs -q startup is roughly the same. And I maintain that many things feel snappier with the optimization flags.

Apropos of the path: have you tried setting your path in, say, `.zshenv`? When I started using that, I was able to shave off a significant amount of time because Emacs didn't have to fire up a full interactive shell to grab the env vars.

This is only on a Mac, right? I'll look into it, not a problem on my other machine.

IME the only thing -march=native does is it makes it impossible to boot your system on an older microarchitecture (which is trivial with Linux otherwise — I really don't understand those who bring their bad Windows habits and do a reinstall when moving between systems).

I mean, it would do that. But, I also have never just moved the hard drive between machines. I've only owned two machines in the last decade. So, not even something I have had a lot of opportunity to do.

Back to the point, though, I'm assuming that libc dynamically does most of the optimizations that native enables?

I second emacs-plus. It's been a very pleasant experience on my new M1, especially relative to the default homebrew version which I could not keep working for more than 10 minutes.

Native comp is great. Most of the speed ups are modest, but it's really noticeable in some really slow operations.

For example, calculating org-table summaries in a very large org file I have (way too large, but I'm too lazy to archive) used to take over 5 minutes. Since I enabled native_comp it completes in under a minute.

What actually is native compilation? Anyone mind explaining?

Emacs lisp can be compiled into bytecode (*.elc files) for faster execution.

Native compilation takes bytecode and compiles (all while doing some smart things like type and value propagation) it into machine code utilising libgccjit.

This results in some very nice speed gains.

The author described the project in his blog here: https://akrl.sdf.org/gccemacs.html

From what I can tell from https://www.emacswiki.org/emacs/GccEmacs - enabling a JIT for Emacs Lisp

It's not a JIT compiler, really. Just one more step (a big one, admittedly) for the existing bytecode compiler.

Aot in a way right ?

Yes, some kind of lazy ahead-of-time compilation.

By default the native compiler kicks in as soon as Emacs finds a bytecompiled file without a machine code equivalent. The resulting machine code is cached then for future use so this only happens once per a single *.elc file.

At least this is what i remember from the last time I checked the code :-)

Compiling to machine code

I like native comp (and major kudos to the devs) but my poor ThinkPad x201 smokes after large ELC cache update.