> The build times are in general constant. The few commits that change > the build time significantly, figured by breaks of the red line in the > graph, are: Thanks for identifying the significant commits. > d12e5d003d deterioration from 78s to 95s (22%) Daniel Colascione Add > portable dumper That's that big jump in January 2019 in the chart above. I wonder whether anybody's taken a look at it again to see if there's anything that can be done more efficiently there. > a350ae058c deterioration from 108s to 129s (19%) Stefan Monnier > * lisp/emacs-lisp/cconv.el: Improve line-nb > info of unused var warnings Hm... is that something that can be improved (if that code is still there, that is)? > fddd63f8b8 and b3d310fa96 deterioration from 129s to 140s (9%) Glenn > Morris Distribute the real source for some doc/misc > manuals (bug#45143) Ah, I suspected that that was the cause of one of the major jumps. > fd31ef21c5 deterioration from 126s to 132s (5%) Alan Mackenzie Don't > use 'load-read-function' in byte-compile-from-buffer > f687e62ac5 deterioration from 132s to 145s (10%) Alan Mackenzie Fix > symbols with position appearing in the output of 'compile-defun' > 6092ee1c3f improvement from 145s to 130s (10%) Alan Mackenzie Amend > byte-run-strip-symbol-positions so that an unexec build builds > 68cdb95019 deterioration from 130s to 136s (5%) Alan Mackenzie Restore > call to byte-run-strip-symbol-positions in byte-compile-out Right; so these weren't in one big commit, so it's more spread out. > Congrats for 1d4e903417, 3e312d11ce and 73a384a986! Thanks. 😃 -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no