Subject: bug#78340: [PATCH] New option for comp *.eln file name by the file timestamp of *.el

From: Andrea Corallo <[email-masked]>
Date: Mon, 12 May 2025 05:30:32 -0400

Eli Zaretskii <[email-masked]> writes:

>> From: Lin Sun <[email-masked]>
>> 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