GNU bug report logs - #77469
finder-inf is not autocompiled on installation

Previous Next

To reply to this bug, email your comments to 77469 AT debbugs.gnu.org.

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

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

From: Gergely Riskó <gergely.risko <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: finder-inf is not autocompiled on installation
Date: Wed, 2 Apr 2025 21:25:48 +0200

Hey,

On a fresh git head `./autogen.sh ; ./configure --prefix=/emacs-test ;
make ; make install` the end-resulting path doesn't have finder-inf
byte compiled:

$ find | grep finder-inf
./share/emacs/31.0.50/lisp/finder-inf.el

This is a bit annoying, because the whole rest of Emacs can be loaded
just from elc files, this is the last holdout.

Cheers,
Gergely

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gergely Riskó <gergely.risko <at> gmail.com>
Cc: 77469 <at> debbugs.gnu.org
Subject: Re: bug#77469: finder-inf is not autocompiled on installation
Date: Thu, 03 Apr 2025 07:44:58 +0300

> From: Gergely Riskó <gergely.risko <at> gmail.com>
> Date: Wed, 2 Apr 2025 21:25:48 +0200
> 
> Hey,
> 
> On a fresh git head `./autogen.sh ; ./configure --prefix=/emacs-test ;
> make ; make install` the end-resulting path doesn't have finder-inf
> byte compiled:
> 
> $ find | grep finder-inf
> ./share/emacs/31.0.50/lisp/finder-inf.el
> 
> This is a bit annoying, because the whole rest of Emacs can be loaded
> just from elc files, this is the last holdout.

Why is it important to compile it?  It defines 2 variables, and has no
code.  What would be gained by compiling it?

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

From: Gergely Riskó <gergely.risko <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 77469 <at> debbugs.gnu.org
Subject: Re: bug#77469: finder-inf is not autocompiled on installation
Date: Fri, 4 Apr 2025 05:17:44 +0200

On Thu, Apr 3, 2025 at 6:45 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
> Why is it important to compile it?  It defines 2 variables, and has no
> code.  What would be gained by compiling it?

Hey Eli, thanks for coming back to me this fast.

The background is this:
https://github.com/radian-software/straight.el/issues/1190

I'm trying to optimize my .emacs, and as part of that, I set up load
suffixes a way, that only .elc is searched, nothing else.

This works, because my whole package setup is byte-compiled with
straight.  Core emacs is byte-compiled in debian, so everything works
out.

The only outlier is this one file.

After my .emacs finished, as the last thing I set back the load suffix
setup to normal, so describe-function and similar stuff works with
.el.gz source files in Debian.  Because of the explosion of load-path
with packages, this trick gives a big win during emacs startup time.

Cheers,
Gergely

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gergely Riskó <gergely.risko <at> gmail.com>
Cc: 77469 <at> debbugs.gnu.org
Subject: Re: bug#77469: finder-inf is not autocompiled on installation
Date: Fri, 04 Apr 2025 13:56:48 +0300

> From: Gergely Riskó <gergely.risko <at> gmail.com>
> Date: Fri, 4 Apr 2025 05:17:44 +0200
> Cc: 77469 <at> debbugs.gnu.org
> 
> On Thu, Apr 3, 2025 at 6:45 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > Why is it important to compile it?  It defines 2 variables, and has no
> > code.  What would be gained by compiling it?
> 
> Hey Eli, thanks for coming back to me this fast.
> 
> The background is this:
> https://github.com/radian-software/straight.el/issues/1190
> 
> I'm trying to optimize my .emacs, and as part of that, I set up load
> suffixes a way, that only .elc is searched, nothing else.

But that's entirely specific to your local setup.  If you want to have
all Lisp files as *.elc, and if you are certain you will never want
Emacs to load a .el file, then just byte-compile finder-inf.el
locally, and be done.  Why do we need to make any changes in Emacs for
such a personal problem?

I can tell right away why such a change as a general feature would be
bad: it is quite possible, perhaps even probable, that users might
have *.el files they don't compile for some reasons, of have *.el
files newer than the corresponding *.elc files, and we definitely
don't want to defeat their loading just because it makes the session
start up slower by 25 milliseconds.

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

From: Gergely Riskó <gergely.risko <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 77469 <at> debbugs.gnu.org
Subject: Re: bug#77469: finder-inf is not autocompiled on installation
Date: Fri, 4 Apr 2025 13:09:27 +0200

[Message part 1 (text/plain, inline)]

On Fri, 4 Apr 2025, 12:57 Eli Zaretskii, <eliz <at> gnu.org> wrote:

> > From: Gergely Riskó <gergely.risko <at> gmail.com>
> > Date: Fri, 4 Apr 2025 05:17:44 +0200
> > Cc: 77469 <at> debbugs.gnu.org
> >
> > On Thu, Apr 3, 2025 at 6:45 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > > Why is it important to compile it?  It defines 2 variables, and has no
> > > code.  What would be gained by compiling it?
> >
> > Hey Eli, thanks for coming back to me this fast.
> >
> > The background is this:
> > https://github.com/radian-software/straight.el/issues/1190
> >
> > I'm trying to optimize my .emacs, and as part of that, I set up load
> > suffixes a way, that only .elc is searched, nothing else.
>
> But that's entirely specific to your local setup.  If you want to have
> all Lisp files as *.elc, and if you are certain you will never want
> Emacs to load a .el file, then just byte-compile finder-inf.el
> locally, and be done.  Why do we need to make any changes in Emacs for
> such a personal problem?
>
> I can tell right away why such a change as a general feature would be
> bad: it is quite possible, perhaps even probable, that users might
> have *.el files they don't compile for some reasons, of have *.el
> files newer than the corresponding *.elc files, and we definitely
> don't want to defeat their loading just because it makes the session
> start up slower by 25 milliseconds.
>

Yes Eli, I'm definitely not advocating to turning off el losing our
changing the suffix logic in any way, because as you mentioned, that would
trip to normal use cases and that's totally unacceptable for 25
milliseconds. My honest apologies if I miscommunicated and made it sound
like that's what I'm advocating for, didn't want to criticize the emacs
team in any way of advocate for big changes like this.

What I'm asking for is just the compilation of this one file in the build
or install process (similar to all the rest), so it's available as elc if
ever needed. It of course should still be kept as el too, as the rest of
the files are kept too (when byte compiled).

The reason why this is not convenient for me to do locally: it's part of
the system packaging that I use (Debian, but I think it would be the same
with other distros). And therefore periodically new version will appear and
I'll have to remember and recompile again.

There is no risk for the end user for this elc compilation to get out of
date, as it's part of the core emacs installation, and therefore read only
on most systems. So the risk is exactly the same as for any other el files
hand modified in the system installation.

Also, I use many machines at different locations, with different emacs
versions, so it's not a one time local change and forget situation, would
be tedious to remember after each apt upgrade.

Thanks again for considering this, I'm of course happy to discuss and
explain why do I need changes in Emacs. Thanks for your continued decades
old maintenance efforts and sorry if I sounded arrogant on my first try,
was not my intention.

>

[Message part 2 (text/html, inline)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gergely Riskó <gergely.risko <at> gmail.com>
Cc: 77469 <at> debbugs.gnu.org
Subject: Re: bug#77469: finder-inf is not autocompiled on installation
Date: Fri, 04 Apr 2025 14:28:03 +0300

> From: Gergely Riskó <gergely.risko <at> gmail.com>
> Date: Fri, 4 Apr 2025 13:09:27 +0200
> Cc: 77469 <at> debbugs.gnu.org
> 
> The reason why this is not convenient for me to do locally: it's part of the system packaging that I use
> (Debian, but I think it would be the same with other distros). And therefore periodically new version will appear
> and I'll have to remember and recompile again. 
> 
> There is no risk for the end user for this elc compilation to get out of date, as it's part of the core emacs
> installation, and therefore read only on most systems. So the risk is exactly the same as for any other el files
> hand modified in the system installation.
> 
> Also, I use many machines at different locations, with different emacs versions, so it's not a one time local
> change and forget situation, would be tedious to remember after each apt upgrade.

I hear you, but OTOH compiling this file will make the build a tad
longer, so it is not coming for free.

In general, we don't compile files that have no code.

Does anyone else have an opinion?

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

From: Gergely Riskó <gergely.risko <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 77469 <at> debbugs.gnu.org
Subject: Re: bug#77469: finder-inf is not autocompiled on installation
Date: Sat, 5 Apr 2025 16:16:22 +0200

> I hear you, but OTOH compiling this file will make the build a tad
> longer, so it is not coming for free.
>
> In general, we don't compile files that have no code.

Yes, now I understand this much better, and that there is no point in
byte-compilation.

Although adding a coding: ascii (or coding: utf-8) declaration at top
would help a little bit, as discussed in
https://github.com/nilcons/emacs-research/tree/master/parse-speed-byte-compile

I also looked into your statement of "In general, we don't compile
files that have no code", because I was wondering how come that this
is the only file that trips up my elc only dotemacs startup scenario
and not the other files that you refer to.

What I found is that the other files (e.g. subdirs.el) are loaded by
explicitly specifying ".el" extension on load.  Could we do that for
this case?  Is that an acceptable compromise to not make the build
slower, but solve my issue?

I'm happy to do the work and provide a patch, but before doing any
work that is potentially incorrect or wrong, I of course wanted to
hear your opinions.  This change would also make the startup a little
bit nicer in the sense that the explicit load with filename (instead
of current filename less require) will also be able to skip the
load-path.

Should we also include the "coding: ascii" on top of the file to make
loading faster?

Cheers,
Gergely

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gergely Riskó <gergely.risko <at> gmail.com>
Cc: 77469 <at> debbugs.gnu.org
Subject: Re: bug#77469: finder-inf is not autocompiled on installation
Date: Sat, 05 Apr 2025 18:44:53 +0300

> From: Gergely Riskó <gergely.risko <at> gmail.com>
> Date: Sat, 5 Apr 2025 16:16:22 +0200
> Cc: 77469 <at> debbugs.gnu.org
> 
> > I hear you, but OTOH compiling this file will make the build a tad
> > longer, so it is not coming for free.
> >
> > In general, we don't compile files that have no code.
> 
> Yes, now I understand this much better, and that there is no point in
> byte-compilation.
> 
> Although adding a coding: ascii (or coding: utf-8) declaration at top
> would help a little bit, as discussed in
> https://github.com/nilcons/emacs-research/tree/master/parse-speed-byte-compile

This shouldn't be necessary, since file-coding-system-alist already
says that *.el files should be decoded as UTF-8.

> I also looked into your statement of "In general, we don't compile
> files that have no code", because I was wondering how come that this
> is the only file that trips up my elc only dotemacs startup scenario
> and not the other files that you refer to.
> 
> What I found is that the other files (e.g. subdirs.el) are loaded by
> explicitly specifying ".el" extension on load.  Could we do that for
> this case?  Is that an acceptable compromise to not make the build
> slower, but solve my issue?

I'll let others comment on that, I'm not sure I understand well enough
the implications for package.el.

> Should we also include the "coding: ascii" on top of the file to make
> loading faster?

Shouldn't be necessary, see above.

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

From: Gergely Riskó <gergely.risko <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 77469 <at> debbugs.gnu.org
Subject: Re: bug#77469: finder-inf is not autocompiled on installation
Date: Sat, 5 Apr 2025 18:00:18 +0200

[Message part 1 (text/plain, inline)]

On Sat, 5 Apr 2025, 17:45 Eli Zaretskii, <eliz <at> gnu.org> wrote:

> > From: Gergely Riskó <gergely.risko <at> gmail.com>
> > Date: Sat, 5 Apr 2025 16:16:22 +0200
> > Cc: 77469 <at> debbugs.gnu.org
> >
> > > I hear you, but OTOH compiling this file will make the build a tad
> > > longer, so it is not coming for free.
> > >
> > > In general, we don't compile files that have no code.
> >
> > Yes, now I understand this much better, and that there is no point in
> > byte-compilation.
> >
> > Although adding a coding: ascii (or coding: utf-8) declaration at top
> > would help a little bit, as discussed in
> >
> https://github.com/nilcons/emacs-research/tree/master/parse-speed-byte-compile
>
> This shouldn't be necessary, since file-coding-system-alist already
> says that *.el files should be decoded as UTF-8.
>

I understand that, but as you see on the page, that's not the case.  I
intentionally compiled the webpage in a way that it's easy to download (git
clone) and reproduce, and I reproduced it on emacs 30.1 and on master
head.  Maybe it works differently in your environment?

El data loading is slower than byte compiled or el with utf8 coding header,
at least for me.

I think the difference is that in the alist elc is strongly utf8, but el is
only "prefer" utf8, do it still needs to spend cycles on some kind of
checking/detection.

Cheers,
Gergely

[Message part 2 (text/html, inline)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gergely Riskó <gergely.risko <at> gmail.com>
Cc: 77469 <at> debbugs.gnu.org
Subject: Re: bug#77469: finder-inf is not autocompiled on installation
Date: Sat, 05 Apr 2025 19:16:50 +0300

> From: Gergely Riskó <gergely.risko <at> gmail.com>
> Date: Sat, 5 Apr 2025 18:00:18 +0200
> Cc: 77469 <at> debbugs.gnu.org
> 
> On Sat, 5 Apr 2025, 17:45 Eli Zaretskii, <eliz <at> gnu.org> wrote:
> 
>  > From: Gergely Riskó <gergely.risko <at> gmail.com>
>  > Date: Sat, 5 Apr 2025 16:16:22 +0200
>  > Cc: 77469 <at> debbugs.gnu.org
>  > 
>  > > I hear you, but OTOH compiling this file will make the build a tad
>  > > longer, so it is not coming for free.
>  > >
>  > > In general, we don't compile files that have no code.
>  > 
>  > Yes, now I understand this much better, and that there is no point in
>  > byte-compilation.
>  > 
>  > Although adding a coding: ascii (or coding: utf-8) declaration at top
>  > would help a little bit, as discussed in
>  > https://github.com/nilcons/emacs-research/tree/master/parse-speed-byte-compile
> 
>  This shouldn't be necessary, since file-coding-system-alist already
>  says that *.el files should be decoded as UTF-8.
> 
> I understand that, but as you see on the page, that's not the case.  I intentionally compiled the webpage in a
> way that it's easy to download (git clone) and reproduce, and I reproduced it on emacs 30.1 and on master
> head.  Maybe it works differently in your environment?
> 
> El data loading is slower than byte compiled or el with utf8 coding header, at least for me. 

Where's the evidence that just adding the utf-8 coding cookie makes it
significantly faster, and by how much?

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

From: Gergely Riskó <gergely.risko <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 77469 <at> debbugs.gnu.org
Subject: Re: bug#77469: finder-inf is not autocompiled on installation
Date: Sat, 5 Apr 2025 21:10:27 +0200

> Where's the evidence that just adding the utf-8 coding cookie makes it
> significantly faster, and by how much?

You are right in that the evidence I provided is only measurable in
bulk, e.g. with run-benchmark and many iterations.

And when I tried to measure it in isolation regarding the startup
time, I noticed that actually the coding is already there at the end
of finder-inf.el, which I didn't notice before.

This seems to be consistent throughout emacs for these auto-generated
non-bytecompiled data holding .el files, they all define utf-8-emacs
or utf-8-emacs-unix at the end in the local variables section (which
is just as effective, as specifying on the top).

The only exception is subdirs.el, which is missing this, but
finder-inf.el definitely has it, sorry for the noise.
So, actually let's skip this part of the discussion and once again, sorry.

The other part is still interesting to me, so as you said, I will wait
for the others to hopefully reply regarding specifying .el explicitly
when loading/requiring finder-inf.el, similarly to subdirs.el.

Cheers,
Gergely

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

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>,
 Gergely Riskó <gergely.risko <at> gmail.com>
Cc: 77469 <at> debbugs.gnu.org
Subject: Re: bug#77469: finder-inf is not autocompiled on installation
Date: Wed, 9 Apr 2025 17:30:20 -0700

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Gergely Riskó <gergely.risko <at> gmail.com>
>> Date: Fri, 4 Apr 2025 13:09:27 +0200
>> Cc: 77469 <at> debbugs.gnu.org
>>
>> The reason why this is not convenient for me to do locally: it's part of the system packaging that I use
>> (Debian, but I think it would be the same with other distros). And therefore periodically new version will appear
>> and I'll have to remember and recompile again.
>>
>> There is no risk for the end user for this elc compilation to get out of date, as it's part of the core emacs
>> installation, and therefore read only on most systems. So the risk is exactly the same as for any other el files
>> hand modified in the system installation.
>>
>> Also, I use many machines at different locations, with different emacs versions, so it's not a one time local
>> change and forget situation, would be tedious to remember after each apt upgrade.
>
> I hear you, but OTOH compiling this file will make the build a tad
> longer, so it is not coming for free.
>
> In general, we don't compile files that have no code.
>
> Does anyone else have an opinion?

No opinion, really.

Maybe we should make the change, if it keeps the startup time chasers
happy.  I guess it depends on whether the rest of us would notice any
difference.

Previous Next

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