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, Andrea Corallo <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 08:02:56 -0400

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

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 ...

On Mon, May 12, 2025, 7:57 AM Eli Zaretskii <eliz <at> gnu.org> wrote:

> > From: Andrea Corallo <acorallo <at> gnu.org>
> > Cc: Lin Sun <sunlin7 <at> hotmail.com>,  78340 <at> debbugs.gnu.org
> > Date: Mon, 12 May 2025 05:30:32 -0400
> >
> > Eli Zaretskii <eliz <at> gnu.org> writes:
> >
> > > Anyway, unless Andrea (CC'ed) enthusiastically embraces this,
> >
> > I don't "enthusiastically embrace" this :).
> >
> > I share all the concerns you have listed, the hash system was
> > constructed exactly to rely on something more robust than timestamps.
>
> Thanks, I presumed you'd think that.
>
> > I'm no Windows expert, why do why see such a performance hit on this
> > system?
>
> Disk I/O is slower, so loading hundreds of packages at startup (which
> is what the OP does, AFAIU) takes time.
>
> On my MS-Windows system, the following command
>
>   time emacs -Q --eval "(progn (message \"foo\") (kill-emacs))"
>
> reports the following times:
>
>   real    00h00m00.149s
>   user    00h00m00.109s
>   sys     00h00m00.031s
>
> This loads the *.eln files for all the preloaded Lisp packages.  In my
> case, there are 162 *.eln files loaded by the above command.  I don't
> know how many *.eln files does the OP have that are loaded at startup,
> but even 1500 of them should load in, like, 1.5 sec, which should be
> still okay for startup (that is supposed to be a rare event).
>
> So I personally don't see this as a serious problem, but maybe I'm
> missing something.
>
>
>
>

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

Previous Next

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