Well, that was fast — less than a month.
But of course, each one of these er sprints are shorter than the previous one. This time we started at 2140 open bugs, and we’re now down to 2022 open bugs, which is a reduction of… Oh, that’s too much math for me.
So the next stretch is just 202 bugs, and will hopefully finally tip us over into below 2K territory. Magical numbers are still magical.
Hopefully there won’t be a B2K problem.
So what’s been going on this time?
Emacs has an old, inefficient garbage collector, and over the years there’s been a number of discussions about swapping it out with something modern. Hopefully that will happen at some point, but meanwhile discussion on emacs-devel recently touched on tuning what we have. Our garbage limits haven’t really been determined by anything but intuition, so we started tinkering a bit — first of all in a batch oriented setting. So why not use the Emacs build itself as the test?
We compile the .el files into .elc files by starting up an Emacs for each .el file, letting it compile the .elc file, and then exit. That’s not super efficient, but it makes the compilation more repeatable, since we don’t have to worry about ordering that much. This also means that the garbage collection isn’t that important: The processes don’t grow that big, and it’s all released anyway when the Emacs process exits.
On my build machine, a complete fresh build takes 1m29s. Simply by upping the gc limits, that’s slashed to 1m4s. Emacs does a lot of other stuff during the build, so byte compilation is really 2x as fast as with the old settings.
On my laptop, a build typically takes around 4 minutes, and upping the gc brings that down to 2m40s.
That’s a pretty massive win for virtually no work (except for Stefan Monnier who has been running a bunch of build processes with different settings to find an optimal one).
I thought it might be nice to have some charts, so I’ve been running Emacs builds continuously for a week on a server out there in the world somewhere. Behold!
Gregory Heytings have gone through the discontinuities in the chart and identified the major leaps (which have all been for good reasons, it turns out). (Probably.)
To zoom in on the gc tweaks:
So on this server, the gc tweaks brought down compilation time from about 125s to about 90s, which is nice. Looking at the CPU usage chart, it’s even better:
From about 1000 CPU seconds to about 650 CPU seconds. Think of all the electricity we’ll be saving, all over the world, from machines sweating less when building Emacs.
It might be as much as half an NFT! Globally! Over several lifetimes!
Finally, to zoom out again on the CPU chart:
We’re basically back to 2018 levels. “Yay.”
Anyway, other than that, I don’t think there’s any particularly noteworthy features this cycle — just a whole lot of bug fixin’ and tiny tweaks. Let’s have a look at the NEWS diff…
Oh, there’s a new command, C-x C-M-+ to adjust the font size in all windows. I think that’s going to be useful… Oh, and Eli added max-redisplay-ticks — it’s an experimental feature to do estimates for “how much work” we’ve been doing in redisplay, and giving up if it seems like redisplay is hanging Emacs (for some values of “hanging”). That’s going to be really helpful, but needs more tweaking.
But I forgot the three major, major, major new features:
Emacs has had commands to rotate images for a long time:
But now you can also flip the images, courtesy of Timo Taipalus:
I know!
And Tetris now has a new (optional) randomisation algorithm — it’s so annoying getting a lot of the same shapes in a row, so if tetris-allow-repetitions is customised to nil, it’ll use a “bag with no putback” algo (courtesy of Timothee Denizou).
But most important of all:
You can now zoom in on emojis (and, well, any other character) and see what they’re meant to depict. (Which can be somewhat difficult with some of the more complicated emojis.)
Fortunately, not all the new features are as momentous as these.
Hm… I should take a vacation soon.