bug#15112: 24.3; package.el byte compile autoloads

bug#15112: 24.3; package.el byte compile autoloads

[Kevin Ryde]

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

bug#15112: 24.3; package.el byte compile autoloads

[Stefan Kangas]

Kevin Ryde <user42@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

bug#15112: 24.3; package.el byte compile autoloads

[Noam Postavsky]

Stefan Kangas <stefan@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.

bug#15112: 24.3; package.el byte compile autoloads

[Stefan Kangas]

Noam Postavsky <npostavs@gmail.com> writes:

> Stefan Kangas <stefan@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

bug#15112: 24.3; package.el byte compile autoloads

[Michael Albinus]

Stefan Kangas <stefan@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.

bug#15112: 24.3; package.el byte compile autoloads

[Stefan Kangas]

Hi Michael,

Michael Albinus <michael.albinus@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")
 	    "\f\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.

bug#15112: 24.3; package.el byte compile autoloads

[Michael Albinus]

Stefan Kangas <stefan@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.

bug#15112: 24.3; package.el byte compile autoloads

[Stefan Kangas]

tags 15112 + wontfix
close 15112
thanks

Michael Albinus <michael.albinus@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.