GNU bug report logs - #15112
24.3; package.el byte compile autoloads

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 15112 in the body.
You can then email your comments to 15112 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Kevin Ryde <user42 <at> zip.com.au>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.3; package.el byte compile autoloads
Date: Sat, 17 Aug 2013 11:04:50 +1000

When package.el installs a file, the foo-autoloads.el which it creates
is not byte compiled.  I hoped that it would be, because doing so allows
the dynamic docstrings stuff to leave possibly big docstrings on disk
until required.

I see package-autoload-ensure-default-file contains

    ";; no-byte-compile: t\n"

which is perhaps copied from autoload-rubric.  Perhaps it could omit
that to allow byte compile.

I have presumed no-byte-compile in loaddefs is for the benefit of emacs'
own loaddefs which are dumped.  Perhaps for everyone else the default
rubric could allow byte compiling.



In GNU Emacs 24.3.1 (i486-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2013-05-29 on blah.blah, modified by Debian
System Description:	Debian GNU/Linux unstable (sid)

Configured using:
 `configure '--build' 'i486-linux-gnu' '--build' 'i486-linux-gnu'
 '--prefix=/usr' '--sharedstatedir=/var/lib' '--libexecdir=/usr/lib'
 '--localstatedir=/var/lib' '--infodir=/usr/share/info'
 '--mandir=/usr/share/man' '--with-pop=yes'
 '--enable-locallisppath=/etc/emacs24:/etc/emacs:/usr/local/share/emacs/24.3/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/24.3/site-lisp:/usr/share/emacs/site-lisp'
 '--with-crt-dir=/usr/lib/i386-linux-gnu' '--with-x=yes'
 '--with-x-toolkit=lucid' '--with-toolkit-scroll-bars' '--without-gconf'
 'build_alias=i486-linux-gnu' 'CFLAGS=-g -O2 -fstack-protector
 --param=ssp-buffer-size=4 -Wformat -Werror=format-security -Wall'
 'LDFLAGS=-Wl,-z,relro -Wl,-znocombreloc'
 'CPPFLAGS=-D_FORTIFY_SOURCE=2''

Important settings:
  value of $LANG: en_AU
  locale-coding-system: iso-latin-1-unix
  default enable-multibyte-characters: t

Message #8 received at 15112 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Kevin Ryde <user42 <at> zip.com.au>
Cc: Noam Postavsky <npostavs <at> gmail.com>, 15112 <at> debbugs.gnu.org
Subject: Re: bug#15112: 24.3; package.el byte compile autoloads
Date: Wed, 28 Aug 2019 15:15:46 +0200

Kevin Ryde <user42 <at> zip.com.au> writes:

> When package.el installs a file, the foo-autoloads.el which it creates
> is not byte compiled.  I hoped that it would be, because doing so allows
> the dynamic docstrings stuff to leave possibly big docstrings on disk
> until required.
>
> I see package-autoload-ensure-default-file contains
>
>     ";; no-byte-compile: t\n"
>
> which is perhaps copied from autoload-rubric.  Perhaps it could omit
> that to allow byte compile.
>
> I have presumed no-byte-compile in loaddefs is for the benefit of emacs'
> own loaddefs which are dumped.  Perhaps for everyone else the default
> rubric could allow byte compiling.

package-autoload-ensure-default-file now uses autoload-rubric internally
and no longer contains the line quoted above with "no-byte-compile".
However, autoload-rubric still contains it.

I guess the question is if it's there for good reason or could perhaps
be omitted.  If there's a good reason for it, perhaps this bug should be
closed as wontfix.

Noam, I noted that you added a comment to this particular line recently
in commit 1f7b602f84.  Could you perhaps shed some light on why we use
no-byte-compile here?

Thanks,
Stefan Kangas

Message #11 received at 15112 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> gmail.com>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: Kevin Ryde <user42 <at> zip.com.au>, 15112 <at> debbugs.gnu.org
Subject: Re: bug#15112: 24.3; package.el byte compile autoloads
Date: Wed, 28 Aug 2019 10:48:24 -0400

Stefan Kangas <stefan <at> marxist.se> writes:

> package-autoload-ensure-default-file now uses autoload-rubric internally
> and no longer contains the line quoted above with "no-byte-compile".
> However, autoload-rubric still contains it.
>
> I guess the question is if it's there for good reason or could perhaps
> be omitted.  If there's a good reason for it, perhaps this bug should be
> closed as wontfix.
>
> Noam, I noted that you added a comment to this particular line recently
> in commit 1f7b602f84.  Could you perhaps shed some light on why we use
> no-byte-compile here?

As the comment says "#$ is byte-compiled into nil", and we use #$ in the
generated autoloaded file.  So byte-compiling would break it.

I think it would work to use load-file-name instead.

Message #14 received at 15112 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: Kevin Ryde <user42 <at> zip.com.au>, 15112 <at> debbugs.gnu.org
Subject: Re: bug#15112: 24.3; package.el byte compile autoloads
Date: Wed, 25 Nov 2020 21:44:41 -0500

Noam Postavsky <npostavs <at> gmail.com> writes:

> Stefan Kangas <stefan <at> marxist.se> writes:
>
>> package-autoload-ensure-default-file now uses autoload-rubric internally
>> and no longer contains the line quoted above with "no-byte-compile".
>> However, autoload-rubric still contains it.
>>
>> I guess the question is if it's there for good reason or could perhaps
>> be omitted.  If there's a good reason for it, perhaps this bug should be
>> closed as wontfix.
>>
>> Noam, I noted that you added a comment to this particular line recently
>> in commit 1f7b602f84.  Could you perhaps shed some light on why we use
>> no-byte-compile here?
>
> As the comment says "#$ is byte-compiled into nil", and we use #$ in the
> generated autoloaded file.  So byte-compiling would break it.
>
> I think it would work to use load-file-name instead.

I made a little experiment and of course byte-compiling these files
gives us a ton of headaches, see below.  So I'm not sure this is all
worth it.  Do we have reason to believe that byte-compiling these files
would give any significant performance increase?


  ELC      net/tramp-loaddefs.elc

In toplevel form:
net/tramp-loaddefs.el:28:36: Warning: reference to free variable
    ‘tramp-methods’
net/tramp-loaddefs.el:28:36: Warning: assignment to free variable
    ‘tramp-methods’
net/tramp-loaddefs.el:28:217: Warning: reference to free variable
    ‘tramp-default-host-alist’
net/tramp-loaddefs.el:28:217: Warning: assignment to free variable
    ‘tramp-default-host-alist’
net/tramp-loaddefs.el:361:175: Warning: reference to free variable
    ‘tramp-default-method-alist’
net/tramp-loaddefs.el:361:175: Warning: assignment to free variable
    ‘tramp-default-method-alist’
net/tramp-loaddefs.el:373:36: Warning: reference to free variable
    ‘tramp-foreign-file-name-handler-alist’
net/tramp-loaddefs.el:373:36: Warning: assignment to free variable
    ‘tramp-foreign-file-name-handler-alist’
  ELC      net/tramp-rclone.elc
net/tramp-loaddefs.el:521:7366: Warning: reference to free variable
    ‘tramp-local-host-regexp’
net/tramp-loaddefs.el:521:7424: Warning: reference to free variable
    ‘tramp-default-user-alist’
  ELC      net/tramp-sh.elc
net/tramp-loaddefs.el:521:7541: Warning: assignment to free variable
    ‘tramp-default-user-alist’

In end of data:
net/tramp-loaddefs.el:768:1: Warning: the following functions are not known to
    be defined: tramp--with-startup, tramp-set-completion-function,
    tramp-tramp-file-p, tramp-file-name-method, tramp-dissect-file-name,
    tramp-register-foreign-file-name-handler, tramp-compat-file-name-quoted-p
  ELC      net/tramp-smb.elc
  ELC      net/tramp-sudoedit.elc
  ELC      net/tramp-uu.elc
  ELC      net/tramp.elc

In toplevel form:
net/tramp-rclone.el:39:1: Error: Symbol’s value as variable is void:
tramp-methods
make[3]: *** [Makefile:295: net/tramp-rclone.elc] Error 1
make[3]: *** Waiting for unfinished jobs....

In toplevel form:
net/tramp-sh.el:35:1: Error: Symbol’s value as variable is void: tramp-methods
make[3]: *** [Makefile:295: net/tramp-sh.elc] Error 1

In toplevel form:
net/tramp-smb.el:31:1: Error: Symbol’s value as variable is void: tramp-methods
make[3]: *** [Makefile:295: net/tramp-smb.elc] Error 1

In toplevel form:
net/tramp-sudoedit.el:37:1: Error: Symbol’s value as variable is void:
tramp-methods
make[3]: *** [Makefile:295: net/tramp-sudoedit.elc] Error 1

In toplevel form:
net/tramp.el:89:1: Error: Symbol’s value as variable is void: tramp-methods
make[3]: *** [Makefile:295: net/tramp.elc] Error 1
make[3]: Leaving directory '/home/skangas/wip/emacs/lisp'
make[2]: *** [Makefile:318: compile-main] Error 2
make[2]: Leaving directory '/home/skangas/wip/emacs/lisp'
make[1]: *** [Makefile:411: lisp] Error 2
make[1]: Leaving directory '/home/skangas/wip/emacs'
make: *** [Makefile:1126: bootstrap] Error 2

Message #17 received at 15112 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: Noam Postavsky <npostavs <at> gmail.com>, 15112 <at> debbugs.gnu.org
Subject: Re: bug#15112: 24.3; package.el byte compile autoloads
Date: Thu, 26 Nov 2020 10:34:24 +0100

Stefan Kangas <stefan <at> marxist.se> writes:

Hi Stefan,

> I made a little experiment and of course byte-compiling these files
> gives us a ton of headaches, see below.  So I'm not sure this is all
> worth it.  Do we have reason to believe that byte-compiling these files
> would give any significant performance increase?
>
>   ELC      net/tramp-loaddefs.elc

I don't know which kind of experiment you have applied, so I cannot say
anything about the compilation errors. However, I wonder where paths
like "net/tramp-loaddefs.elc" come from. We're speaking about
package.el, meaning we're speaking about ELPA. Tramp in ELPA doesn't use
any subdirectory "net".

Anyway, I don't believe we'll see a performance boost after
byte-compiling loaddef files. They just contain function and variable
declarations, no implementation (but the initial values of variables).

There are exceptions like in tramp-loaddefs.el, but they still don't
count wrt performance, I believe.

Best regards, Michael.

Message #20 received at 15112 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: Noam Postavsky <npostavs <at> gmail.com>, 15112 <at> debbugs.gnu.org
Subject: Re: bug#15112: 24.3; package.el byte compile autoloads
Date: Thu, 26 Nov 2020 05:18:36 -0500

Hi Michael,

Michael Albinus <michael.albinus <at> gmx.de> writes:

>> I made a little experiment and of course byte-compiling these files
>> gives us a ton of headaches, see below.  So I'm not sure this is all
>> worth it.  Do we have reason to believe that byte-compiling these files
>> would give any significant performance increase?
>>
>>   ELC      net/tramp-loaddefs.elc
>
> I don't know which kind of experiment you have applied, so I cannot say
> anything about the compilation errors. However, I wonder where paths
> like "net/tramp-loaddefs.elc" come from. We're speaking about
> package.el, meaning we're speaking about ELPA. Tramp in ELPA doesn't use
> any subdirectory "net".

I used this patch:

diff --git a/lisp/emacs-lisp/autoload.el b/lisp/emacs-lisp/autoload.el
index 07bda537b3..e32d74fa7c 100644
--- a/lisp/emacs-lisp/autoload.el
+++ b/lisp/emacs-lisp/autoload.el
@@ -373,7 +373,7 @@ autoload-rubric
 	    ";;; Code:\n\n"
 	    (if lp
 		"(add-to-list 'load-path (directory-file-name
-                         (or (file-name-directory #$) (car load-path))))\n\n")
+                         (or (file-name-directory load-file-name)
(car load-path))))\n\n")
 	    "\n"
 	    ;; This is used outside of autoload.el, eg cus-dep, finder.
 	    (if feature
@@ -382,7 +382,6 @@ autoload-rubric
 			  (file-name-sans-extension basename))))
 	    ";; Local Variables:\n"
 	    ";; version-control: never\n"
-            ";; no-byte-compile: t\n" ;; #$ is byte-compiled into nil.
 	    ";; no-update-autoloads: t\n"
 	    ";; coding: utf-8\n"
 	    ";; End:\n"

And ran "make bootstrap".

> Anyway, I don't believe we'll see a performance boost after
> byte-compiling loaddef files. They just contain function and variable
> declarations, no implementation (but the initial values of variables).
>
> There are exceptions like in tramp-loaddefs.el, but they still don't
> count wrt performance, I believe.

This would be my guess too.  It seems like more trouble than it's worth.

Message #23 received at 15112 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: Noam Postavsky <npostavs <at> gmail.com>, 15112 <at> debbugs.gnu.org
Subject: Re: bug#15112: 24.3; package.el byte compile autoloads
Date: Thu, 26 Nov 2020 12:53:43 +0100

Stefan Kangas <stefan <at> marxist.se> writes:

> Hi Michael,

Hi Stefan,

>> Anyway, I don't believe we'll see a performance boost after
>> byte-compiling loaddef files. They just contain function and variable
>> declarations, no implementation (but the initial values of variables).
>>
>> There are exceptions like in tramp-loaddefs.el, but they still don't
>> count wrt performance, I believe.
>
> This would be my guess too.  It seems like more trouble than it's worth.

So I recommend to close the bug. Maybe you'll wait some few days whether
somebody objects.

Best regards, Michael.

Message #26 received at 15112 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: Noam Postavsky <npostavs <at> gmail.com>, 15112 <at> debbugs.gnu.org
Subject: Re: bug#15112: 24.3; package.el byte compile autoloads
Date: Fri, 1 Jan 2021 12:56:15 -0600

tags 15112 + wontfix
close 15112
thanks

Michael Albinus <michael.albinus <at> gmx.de> writes:

>>> Anyway, I don't believe we'll see a performance boost after
>>> byte-compiling loaddef files. They just contain function and variable
>>> declarations, no implementation (but the initial values of variables).
>>>
>>> There are exceptions like in tramp-loaddefs.el, but they still don't
>>> count wrt performance, I believe.
>>
>> This would be my guess too.  It seems like more trouble than it's worth.
>
> So I recommend to close the bug. Maybe you'll wait some few days whether
> somebody objects.

No further comments within 5 weeks, so I'm closing this as wontfix.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.