>> I have thought a possible solution to this problem: load the byte-compiled
>> file and put the native-compiled version in a list. Then load that list one by
>> one on an idle-timer, that way the UI freezes should be minimized. This could
>> reuse the "late loading" machinery implemented for deferred compilation.
> I believe we didn't investigate this issue well enough to understand
> what happens and why. Would it be possible to investigate this soon?
> It could be after the patches are installed.
I profiled Emacs and found out that most of the time it was blocked on a call to
wopen().
A non-native-comp build will try to open these files in each path in
`load-path':
- foo.dll.gz
- foo.dll.gz
- foo.elc.gz
- foo.elc
- foo.el.gz
- foo.el
The native-comp build with try to open these files instead:
- eln-$HASH/foo.eln
- eln-$HASH/foo.eln.gz
- eln-$HASH/foo.dll
- eln-$HASH/foo.dll.gz
- eln-$HASH/foo.elc
- eln-$HASH/foo.elc.gz
- eln-$HASH/foo.el
- eln-$HASH/foo.el.gz
- foo.eln
- foo.eln.gz
- foo.dll
- foo.dll.gz
- foo.elc
- foo.elc.gz
- foo.el
- foo.el.gz
This is a 166% percent increase in calls to wopen(). Moreover, it is trying to
open some files that don't make sense (*.dll.gz and *.eln.gz) and it's testing
the eln-$HASH directory for *.el and *.elc files.
This is what is should be probing:
- eln-$HASH/foo.eln (only native-comp)
- foo.eln (only native-comp)
- foo.dll
- foo.elc
- foo.elc.gz
- foo.el
- foo.el.gz
This is "only" a 40% increase. I don't think we can do much better here. That
is, unless we implement some kind of cache, but that would be an extreme
solution.
This problem shows in Windows because the NT kernel is slow at file access (See
https://github.com/Microsoft/WSL/issues/873#issuecomment-425272829).
The same thing happens to Git for Windows in my experience.