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

Previous Next

Package: emacs;

Reported by: Lin Sun <sunlin7 <at> hotmail.com>

Date: Sat, 10 May 2025 00:14:02 UTC

Severity: normal

Tags: patch

Done: Eli Zaretskii <eliz <at> gnu.org>

Full log


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

From: Andrea Corallo <acorallo <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Lin Sun <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 05:30:32 -0400
Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Lin Sun <sunlin7 <at> hotmail.com>
>> Date: Sat, 10 May 2025 00:07:52 +0000
>> 
>> Currently Emacs with native comp will comp .eln file name by the
>> full context of the .el or .el.gz file in function
>> "comp-el-to-eln-rel-filename".
>> For example, emacs startup will require the simple.elc, then have to read full of simple.el.gz to calculate the name simple-X-Y.eln. 
>> 
>> That's slow on Windows.
>> 
>> This patch introduced a new option "fts" (file time stamp) for
>> "--with-native-compile", it will let the function
>> "comp-el-to-eln-rel-filename" to get the .eln name by reading the
>> .el/.el.gz file timestamp, make emacs faster on Windows. On my
>> Windows testing env, the Emacs startup up time was reduced from 8s
>> to 6.5s with 386 packages, speedup ~20%.
>
> Is this with a cold disk cache or a warm disk cache?  IOW, if you
> start Emacs, then kill the Emacs session, and then start it again, do
> you still measure 8 sec or do you measure a significantly shorter
> time?
>
> Also, is your anti-virus software configured to ignore *.eln files in
> the directories where you install them?  The *.eln files are DLLs as
> far as Windows is concerned, so it's executable code, and anti-virus
> software will therefore generally scan them when accessed or loaded,
> which could significantly slow down loading.
>
> 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.

I'm no Windows expert, why do why see such a performance hit on this
system?

  Andrea




This bug report was last modified 24 days ago.

Previous Next


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