GNU bug report logs - #78340
[PATCH] New option for comp *.eln file name by the file timestamp of *.el

Previous Next

Full log

View this message in rfc822 format

From: Lynn Winebarger <owinebar <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: sunlin7 <at> hotmail.com, acorallo <at> gnu.org, 78340 <at> debbugs.gnu.org
Subject: bug#78340: [PATCH] New option for comp *.eln file name by the file timestamp of *.el
Date: Mon, 12 May 2025 09:49:19 -0400

On Mon, May 12, 2025 at 9:42 AM Lynn Winebarger <owinebar <at> gmail.com> wrote:
>
> On Mon, May 12, 2025 at 9:33 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
> >
> > > From: Lynn Winebarger <owinebar <at> gmail.com>
> > > Date: Mon, 12 May 2025 09:07:06 -0400
> > > Cc: acorallo <at> gnu.org, sunlin7 <at> hotmail.com, 78340 <at> debbugs.gnu.org
> > >
> > > On Mon, May 12, 2025 at 8:16 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > > >
> > > > > From: Lynn Winebarger <owinebar <at> gmail.com>
> > > > > Date: Mon, 12 May 2025 08:02:56 -0400
> > > > > Cc: Andrea Corallo <acorallo <at> gnu.org>, sunlin7 <at> hotmail.com, 78340 <at> debbugs.gnu.org
> > > > >
> > > > > 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

Previous Next

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