* bug#15112: 24.3; package.el byte compile autoloads
@ 2013-08-17 1:04 Kevin Ryde
2019-08-28 13:15 ` Stefan Kangas
0 siblings, 1 reply; 8+ messages in thread
From: Kevin Ryde @ 2013-08-17 1:04 UTC (permalink / raw)
To: 15112
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#15112: 24.3; package.el byte compile autoloads
2013-08-17 1:04 bug#15112: 24.3; package.el byte compile autoloads Kevin Ryde
@ 2019-08-28 13:15 ` Stefan Kangas
2019-08-28 14:48 ` Noam Postavsky
0 siblings, 1 reply; 8+ messages in thread
From: Stefan Kangas @ 2019-08-28 13:15 UTC (permalink / raw)
To: Kevin Ryde; +Cc: Noam Postavsky, 15112
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#15112: 24.3; package.el byte compile autoloads
2019-08-28 13:15 ` Stefan Kangas
@ 2019-08-28 14:48 ` Noam Postavsky
2020-11-26 2:44 ` Stefan Kangas
0 siblings, 1 reply; 8+ messages in thread
From: Noam Postavsky @ 2019-08-28 14:48 UTC (permalink / raw)
To: Stefan Kangas; +Cc: Kevin Ryde, 15112
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#15112: 24.3; package.el byte compile autoloads
2019-08-28 14:48 ` Noam Postavsky
@ 2020-11-26 2:44 ` Stefan Kangas
2020-11-26 9:34 ` Michael Albinus
0 siblings, 1 reply; 8+ messages in thread
From: Stefan Kangas @ 2020-11-26 2:44 UTC (permalink / raw)
To: Noam Postavsky; +Cc: Kevin Ryde, 15112
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#15112: 24.3; package.el byte compile autoloads
2020-11-26 2:44 ` Stefan Kangas
@ 2020-11-26 9:34 ` Michael Albinus
2020-11-26 10:18 ` Stefan Kangas
0 siblings, 1 reply; 8+ messages in thread
From: Michael Albinus @ 2020-11-26 9:34 UTC (permalink / raw)
To: Stefan Kangas; +Cc: Noam Postavsky, 15112
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#15112: 24.3; package.el byte compile autoloads
2020-11-26 9:34 ` Michael Albinus
@ 2020-11-26 10:18 ` Stefan Kangas
2020-11-26 11:53 ` Michael Albinus
0 siblings, 1 reply; 8+ messages in thread
From: Stefan Kangas @ 2020-11-26 10:18 UTC (permalink / raw)
To: Michael Albinus; +Cc: Noam Postavsky, 15112
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.
^ permalink raw reply related [flat|nested] 8+ messages in thread
* bug#15112: 24.3; package.el byte compile autoloads
2020-11-26 10:18 ` Stefan Kangas
@ 2020-11-26 11:53 ` Michael Albinus
2021-01-01 18:56 ` Stefan Kangas
0 siblings, 1 reply; 8+ messages in thread
From: Michael Albinus @ 2020-11-26 11:53 UTC (permalink / raw)
To: Stefan Kangas; +Cc: Noam Postavsky, 15112
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#15112: 24.3; package.el byte compile autoloads
2020-11-26 11:53 ` Michael Albinus
@ 2021-01-01 18:56 ` Stefan Kangas
0 siblings, 0 replies; 8+ messages in thread
From: Stefan Kangas @ 2021-01-01 18:56 UTC (permalink / raw)
To: Michael Albinus; +Cc: Noam Postavsky, 15112
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2021-01-01 18:56 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-08-17 1:04 bug#15112: 24.3; package.el byte compile autoloads Kevin Ryde
2019-08-28 13:15 ` Stefan Kangas
2019-08-28 14:48 ` Noam Postavsky
2020-11-26 2:44 ` Stefan Kangas
2020-11-26 9:34 ` Michael Albinus
2020-11-26 10:18 ` Stefan Kangas
2020-11-26 11:53 ` Michael Albinus
2021-01-01 18:56 ` Stefan Kangas
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.