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

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 <[email-masked]> wrote:

> > From: Andrea Corallo <[email-masked]>
> > Cc: Lin Sun <[email-masked]>,  [email-masked]
> > Date: Mon, 12 May 2025 05:30:32 -0400
> >
> > Eli Zaretskii <[email-masked]> 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.
>
>
>
>