Subject: bug#78340: [PATCH] New option for comp *.eln file name by the file timestamp of *.el

From: Lynn Winebarger <[email-masked]>
Date: Mon, 12 May 2025 09:49:19 -0400

On Mon, May 12, 2025 at 9:42 AM Lynn Winebarger <[email-masked]> wrote:
>
> On Mon, May 12, 2025 at 9:33 AM Eli Zaretskii <[email-masked]> wrote:
> >
> > > From: Lynn Winebarger <[email-masked]>
> > > Date: Mon, 12 May 2025 09:07:06 -0400
> > > Cc: [email-masked], [email-masked], [email-masked]
> > >
> > > On Mon, May 12, 2025 at 8:16 AM Eli Zaretskii <[email-masked]> wrote:
> > > >
> > > > > From: Lynn Winebarger <[email-masked]>
> > > > > Date: Mon, 12 May 2025 08:02:56 -0400
> > > > > Cc: Andrea Corallo <[email-masked]>, [email-masked], [email-masked]
> > > > >
> > > > > If he has that many packages, his load path has hundreds of entries, and any preloaded library will look in
> > > > > every one before finding it in the last entry ...
> > > >
> > > > Maybe so, but that's a separate problem.  The patch submitted in this
> > > > bug was to shortcut the hashing of the source *.el files, not to avoid
> > > > searching the extra directories.
> > > >
> > > > If the number of directories is the issue, then my suggestion is not
> > > > to compile packages AOT, which AFAIU will cause all the *.eln files to
> > > > be written to a single subdirectory of the eln-cache (after
> > > > compiling them the first time each one is loaded).  But that is a
> > > > separate issue which IMO should be discussed with Stefan and Philip,
> > > > because it's related to how third-party packages are installed and
> > > > compiled.
> > >
> > > It's not the AOT that's the issue, it's the search for the source file
> > > to compute the content hash.
> >
> > Then the time I measured includes that, for the preloaded packages.
>
> That's true - he's only seeing a 20% speedup.
>
> I don't really follow the logic on why the content hash of the current
> source is required to keep emacs from *crashing*, as opposed to just
> being inconsistent with the current source.  That state of affairs has
> always been considered acceptable for byte compiled libraries.
> So, instead of checking file times, why not just put the content hash
> in the .elc, and if loading the elc would be acceptable (determined by
> file times), then use the value from the elc file (stored in the
> comment block at the start so the Fread procedure is not required).

Or, for system-installed libraries, treat them like doc strings and
store them in a file in the etc subdirectory?
Those are not mutually exclusive.  The first would apply to all .elns,
while the second would skip the whole locate-file procedure for system
libraries (if the eln is in the system directory as well).

Lynn