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

Previous Next

Full log

Message #20 received at 78340 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andrea Corallo <acorallo <at> gnu.org>
Cc: sunlin7 <at> hotmail.com, 78340 <at> debbugs.gnu.org
Subject: Re: bug#78340: [PATCH] New option for comp *.eln file name by the
 file timestamp of *.el
Date: Mon, 12 May 2025 14:56:12 +0300

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

Previous Next

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