|
From: | GNU bug Tracking System |
Subject: | bug#38619: closed (Byte compilation of Emacs autoloads) |
Date: | Fri, 28 Feb 2020 13:27:01 +0000 |
Your message dated Fri, 28 Feb 2020 13:25:50 +0000 with message-id <address@hidden> and subject line Re: [bug#38619] Byte compilation of Emacs autoloads has caused the debbugs.gnu.org bug report #38619, regarding Byte compilation of Emacs autoloads to be marked as done. (If you believe you have received this mail in error, please contact address@hidden.) -- 38619: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=38619 GNU Bug Tracking System Contact address@hidden with problems
--- Begin Message ---Subject: Byte compilation of Emacs autoloads Date: Sun, 15 Dec 2019 13:30:36 +0900 User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) Hello, The following adds support for byte compiling the generated autoload files as well as the site-lisp directory of Emacs (the one containing the site-start.el and guix-emacs.el files). The performance gain is roughly 30%, as expected for byte compiled Elisp. The following command was used for benchmarking: --8<---------------cut here---------------start------------->8--- ./pre-inst-env guix environment -v 10 -m ~/100-emacs-packages-manifest.scm -- emacs -Q --batch --eval "(progn (require 'guix-emacs) (message \"%s\" (benchmark-run-compiled 10 (guix-emacs-autoload-packages))))" --8<---------------cut here---------------end--------------->8--- It loads the autoloads of ~100 Emacs packages 10 times (~1000 autoloads files). The manifest file 100-emacs-packages-manifest.scm is attached.100-emacs-packages-manifest.scm
Description: Binary dataThe above command for Guix before the changes (commit e19a539): --8<---------------cut here---------------start------------->8--- [...] Loading /gnu/store/lj09yx56hgsq9l4ajk5wlxsk4vbrympk-profile/share/emacs/site-lisp/undercover-autoloads.el (source)... Loading /gnu/store/lj09yx56hgsq9l4ajk5wlxsk4vbrympk-profile/share/emacs/site-lisp/with-editor-autoloads.el (source)... Loading /gnu/store/lj09yx56hgsq9l4ajk5wlxsk4vbrympk-profile/share/emacs/site-lisp/ws-butler-autoloads.el (source)... Loading /gnu/store/lj09yx56hgsq9l4ajk5wlxsk4vbrympk-profile/share/emacs/site-lisp/yasnippet-autoloads.el (source)... (9.971024566 159 2.763721703999999) --8<---------------cut here---------------end--------------->8--- After the changes: --8<---------------cut here---------------start------------->8--- Loading /gnu/store/fwji52vg31xmdkc2z5cbjrfza7fxndr5-profile/share/emacs/site-lisp/undercover-autoloads... Loading /gnu/store/fwji52vg31xmdkc2z5cbjrfza7fxndr5-profile/share/emacs/site-lisp/with-editor-autoloads... Loading /gnu/store/fwji52vg31xmdkc2z5cbjrfza7fxndr5-profile/share/emacs/site-lisp/ws-butler-autoloads... Loading /gnu/store/fwji52vg31xmdkc2z5cbjrfza7fxndr5-profile/share/emacs/site-lisp/yasnippet-autoloads... (7.435941036 143 2.406266451999999) --8<---------------cut here---------------end--------------->8--- I think it's neat that all of our Elisp is byte compiled; it's something that can be done without fear on Guix, given that when the Emacs package itself changes, all the Emacs packages are rebuilt. It could also find issues we'd not know existed otherwise, as I found out for the emacs-cl-generic package.0001-gnu-emacs-Byte-compile-the-site-lisp-directory.patch
Description: Text Data0002-emacs-build-system-Byte-compile-the-autoload-files.patch
Description: Text Data0003-gnu-emacs-cl-generic-Disable-byte-compilation-of-its.patch
Description: Text DataMaxim
--- End Message ---
--- Begin Message ---Subject: Re: [bug#38619] Byte compilation of Emacs autoloads Date: Fri, 28 Feb 2020 13:25:50 +0000 Hi Pierre! On February 28, 2020 7:03:42 AM UTC, Pierre Neidhardt <address@hidden> wrote: >Hi Maxim, > >Maxim Cournoyer <address@hidden> writes: > >> Eager macro-expansion failure: (file-missing "Searching for program" >"No such file or directory" "git") >> Searching for program: No such file or directory, git > >What's up with that? Is this an problem in one of our packages? It looks like evaluating the emacs-tuareg autoload file causes the message to be emitted. I'd look this way. >> ; "emacs-edbi" ;build fails >> ; "emacs-edbi-sqlite" ;(depends on emacs-edbi) If I'm not mistaken, Efraim promptly fixed those already, after I reported it. I'm closing this bug, since the changes have been merged to master. Enjoy! Maxim
--- End Message ---
[Prev in Thread] | Current Thread | [Next in Thread] |