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