Is it only me, or did Emacs without native comp get faster lately?

Ok, due to the latest Arch update of latest gcc & gcc-libs (they package it so), libgccjit was broken. I had to uninstall it so I could upgrade rest of the system, and my Emacs didn't start due to missing libgccjit.so. So I quickly recompiled Emacs without native compiler, and surprise. I don't even miss native compiler. I used to see a difference in Helm and some other places like a year ago when native comp was in its early stages. I don't have benchmarks, but my Emacs seems like even smoother without native comp for some reason. There are no hiccups, no waiting for completions to pop up. What happened? I run current master, re-compiled like 2 days ago. I now even wonder if I will enable native comp again. Is it just me, or do other people experience similar?

The primitives concat, append, etc. were optimised recently. You are probably seeing the results of this optimisation.

Aha. Thanks, sounds great. Yes it could be that.

and that would also affect Emacs *with* native compilation, if I understand correctly...

No amount of "talking about your feelings" will drive any conclusions regarding a hard metric like instructions per unit time. Typical usage patterns are sufficiently more I/O versus CPU-bound, and the differences perceptible only at scale, that the placebo effect should dominate.

I prefer to use this - https://archlinux.pkgs.org/rolling/home-thaodan-x86_64/libgccjit-11.2.0-1-x86_64.pkg.tar.xz.html and reinstall emacs + native comp I hope libgccjit will be in mainstream repo sooner rather than later.

PKBUILD for libgccjit in AUR was updated the next day, so I already have a working one, but thanks anyway.

> Typical usage patterns are sufficiently more I/O versus CPU-bound, and the differences perceptible only at scale, that the placebo effect should dominate. I can hardly see this being true. Files are loaded from disk into buffers only once after that it is all in memory. Furthermore, to give a concrete example undo with undo-tree enabled takes a perceptably long time converting the undo-list into the tree, and that is all CPU. Running macros also takes forever even on ranges only in the triple digits.

> I can hardly see this being true. The rule of thumb regarding placebo effectiveness is 50%. Hey, I don't make the rules regarding human nature.

> converting the undo-list into the tree, and that is all CPU. I'm sure it is. The question is can you robustly tell whether that conversion is occurring faster or slower between emacs sessions.

Native comp degrades in performance if I run emacs for a few days without shutting down. High CPU spikes that won't come down. I am not sure whether my GC settings are to blame. 🤔 (setq gc-cons-threshold (* 512 1024 1024)) (run-with-idle-timer 5 t (lambda () (garbage-collect)))

Emacs did have some troubles with memory, there was a huge thread on a mailing list like a year ago or something, but I think that should have being solved. If you experience problems, report those as a bug. I don't have any computer that I run for several days in a row, so I am not the one who can help you, but probably someone here or even better on emacs-devel can.

I don't know about recent changes but the Emacs interpreter has gotten much faster over time. I regularly run tests against 24, 25, 26, 27, 28, and now 29. The time it takes to do a first time bring up of a init.el with lots of packages to download and compile has decreased significantly, the improvements are really quite impressive when you see the performance side by side.

The high setting of `gc-cons-threshold` is dangerous and I recommend against it. Running GC every 5 sec won't solve the problems that such a high setting can cause. It could well be the contributing factor to what you see, because Emacs with native-compilation typically uses 50% more memory, at least IME.

There was also a bunch of changes (by the same author, M. Engdegård) which improved the byte-code interpreter in other ways. But those should only amount to a (very roughly) 10% improvement, not an order of a magnitude.

And if you are curious how this was done: * faster concat, etc.: http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=697723b63d69ee6d32a82ab2c88e0ce1e65257ed * micro-optimizations for the above: http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=a3aeee88aaf843de49e4815e4b2d61743e423441 * speedup string size counting for multibyte strings: http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=3b7d55a8013914b6707211d148a6e878ca118ad9 * inline fixnum operations in the bytecode interpreter: http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=6c000af611419745cc7f6c5ea1df1ed961cd6ec3 And more; Mattias Engdegård is doing some nice work.

10% is still pretty nice.

Yup. Just unlikely to give the "wow" effect by itself.

Could you share some numbers?

How do I download a .tar.gz with these changes included? IOW where is the "bleeding edge" source download?

> IOW where is the "bleeding edge" source download? git clone https://git.savannah.gnu.org/git/emacs.git

Thank you for posting! Very nice work by Mattias. I would never even look at those basic operations, I thought they were already like optimized as much as they could be :).

The reason for such high heap settings is because I am running lsp-mode on a multi-million LOC codebase. With low heap values, it was noticeably slow. If Emacs native mode uses more memory why the advice against high heap settings? Or did you mean frequent GC is bad?

I know! Inlining fixnum operations is a super-basic optimization in Lisp systems; I would have thought that sort of thing was done already. Same with separating out string and vector cases for concat, etc....

Wow, I experienced the same. I thought it’s just because of the new hardware, tho as I remember, completion tooltips were laggy regardless of the hardware I used.

How do I fund people working on improving emacs?

It's in OpenSUSE Tumbleweed 😃.

Short version: 24, 25, 26, 27 : slow, 42s, 29s, 27s. Everything is hard to measure. I've looked into getting some numbers that are sufficiently controlled as to be interpretable for something like this, but it isn't easy. My usual test involves requiring the builtin version of org-mode for each version of Emacs, and in that case the time increases with version because newer versions of org-mode do more work the first time they are required. Loading an init file from scratch also isn't a good control due to variability in network latency and because for 24 I have to use straight to install old version of org and magit. That said, the best numbers I can give that show this are for 25, 26, and 27, where times go from 42 seconds, to 29 seconds, to 27 seconds. In this test 28 jumps up to 35 or 36 but that is on an unknown pre-release version, 29 is back down to 29 seconds. The numbers come from running (e.g.) `time emacs-27 -Q -eval "(setq init-simple-testing t)" -l init-simple.el -eval "(kill-emacs)"` where init-simple.el is https://github.com/tgbugs/orgstrap/blob/bc981b957967be8d872c08be9ba7f2dbde5caf1d/init-simple.el.

> With low heap values, it was noticeably slow. Which "low values" of the GC threshold did you try? I find it hard to believe that every value between the default 0.8MB and your 512MB produced a noticeably slow operation. Frequent GC is not bad. What *is* bad is waiting for 0.5GB of garbage to be produced before triggering a GC.

`init-simple.el` and installing org are mostly about disk and network I/O. The alluded to speedups are instruction-related, as fragglerock appears to suggest. Personally I run in my CI: src/emacs -batch -l ./elisp-benchmarks/elisp-benchmarks.el -f elisp-benchmarks-run where `elisp-benchmarks` (from the good egg that also brought you native compilation) is an ELPA package.

That command fails on the linux system I want to build emacs on. It has very restricted access to the internet. It's a corporate firewall thing. I was able to download a bleeding edge tarball.

I meant whatever the default heap size that Emacs uses. Also, the GC is triggered after 5 seconds of inactivity isn't it? Which happens several times during the course of editing any file. Anyways, I will try running with lower heap sizes.

Then extract it in some folder and follow the instructions. But to build Emacs you will need lots of other tools and libraries. Are you sure you have those installed or that you can install those? Maybe talk to your sysadmin and ask for help?

> src/emacs -batch -l ./elisp-benchmarks/elisp-benchmarks.el -f elisp-benchmarks-run That sounds like a much better measurement indeed. Here are a few other benchmarks by creator of Helpful: https://github.com/Wilfred/emacsbench.

> > > My usual test involves requiring the builtin version of org-mode for each version of Emacs, and in that case the time increases with version because newer versions of org-mode do more work the first time they are required. That sounds like a very bad measure, since org-mode changes between versions as well. I am not that familiar with org-mode codebase, but it is an active project, and code base changed significantly over the years. It is not just new functionality and getting bigger over the years, but implementation of algorithms and code in general used in org-mode could have also got better over the years too. It means that newer versions of org-mode could have got more efficient, not just Emacs, so you can not be sure how much of Emacs performance you measure there. In general, I do agree with your original comment, Emacs has got faster over the years in many aspects. > Loading an init file from scratch also isn't a good control due to variability in network latency and because for 24 I have to use straight to install old version of org and magit. Unless you are measuring network metrics, the network shouldn't play any role in Emacs measurements. If you measure Emacs performance, then you should probably preload all your files and packages you need to minimize impact of I/O and network latencies. Also check the benchmark.el for some benchmarking functions.

It's built, installed, and running. I've been using emacs since 1986. Have a nice day. I downloaded the tarball [from the source repository](https://git.savannah.gnu.org/cgit/emacs.git).

My recommendation is to double the default threshold, and then keep doubling it until you get to a reasonable performance. If performance never gets reasonable, stop at the value where performance no longer improves significantly. Use the lowest value of the GC threshold you find this way. I don't expect you to get anywhere near 0.5 GB this way. The fact that you run GC from an idle timer doesn't help when Emacs runs some Lisp code that takes a lot of time and produces a lot of garbage, because idle timers don't run unless Emacs is idle. So some Lisp that produces a lot of garbage can easily cause you bloat your memory footprint, which at best means Emacs might have problems returning memory to the OS due to fragmentation, and at worst could mean an unpleasant meeting with the OOM killer.

I second the question