bug#64712: 29.0.92; Emacs 29 with native compilation compiles cl-loaddefs.el on every startup

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Sat, 2 Sep 2023 14:50:08 -0700
> Cc: Dmitry Gutov <dmitry@gutov.dev>, stephen.molitor@icloud.com, 
> 64712@debbugs.gnu.org
> 
> Andrea Corallo <acorallo@gnu.org> writes:
> 
> > Eli Zaretskii <eliz@gnu.org> writes:
> >
> >>> Date: Thu, 27 Jul 2023 16:36:18 +0300
> >>> Cc: stephen.molitor@icloud.com, 64712@debbugs.gnu.org
> >>> From: Dmitry Gutov <dmitry@gutov.dev>
> >>>
> >>> I suppose another approach would be along the lines of creating, for
> >>> every such file, an artefact in native-compile cache anyway, with
> >>> contents which would load the original uncompiled file (I'm assuming
> >>> this step won't require extracting the file?).
> >>>
> >>> Not sure if this is worth the hassle, though.
> >>
> >> It definitely isn't.
> >
> > The closest solution to what Dmitry suggested is to actually remove the
> > cookie from the file so the eln is produced and we don't try to compile
> > it anymore.  It doesn't harm, again not the most elegant exit strategy
> > but at least is for free :)
> 
> What was the reason that those cookies were added in the first place?

Not to slow down the build unnecessarily, I think.  Basically, the
same reason why we have "no-byte-compile: t" in some files: you get no
gains from doing that, you just waste CPU time.  And the waste is much
more significant with native compilation.

> I see that they were added in commit 6c11214dc112, but it doesn't
> explain why.

When that happens, I always search the mailing lists around the date
of the commit.  In this case, I found

  https://lists.gnu.org/archive/html/emacs-devel/2022-09/msg00168.html

> I personally can't see that it would make much of a difference if we
> have them or not, but maybe I'm missing something.

If nothing else, it will slow down startup (because each .eln files
needs to be loaded via dlopen, as opposed to .elc that is dumped into
the pdumper file), albeit insignificantly.  But if we do this with all
the autoload files we have, that could slow down in a more tangible
ways.  So basically we have here two minor annoyances: you can solve
one, but then you "gain" the other one.