Re: Deferring native compilation finalization until idle

On Sat, Jul 25, 2026 at 9:04 AM, Stéphane Marks < [email protected] > wrote:

> 
> FWIW, my eln-cache this morning , starting fresh from Thursday , has 146
> files with seldom used packages uncompiled, of course.  Rebuilding that
> cache was entirely asynchronous, perhaps except for the trampolines.  I
> have not tried setting native-comp-enable-subr-trampolines to nil in
> early-init.el to see if this bypasses the delays that you're seeing.  Have
> you tried that?
> 
> 
>> 
>> 
>> 
> 
> 

Setting native-comp-enable-subr-trampolines to nil does not noticeably reduce the stutter for me.

Ending up with only 146 files likely means that even if you were to not have one of the workarounds in place, you would not notice as much stutter as one who had more.

My guess is that if you were to try my config, or someone else's that notices the issue and not disable macOS's security checks, you too would notice the stutter.

I work with others that use macOS. I can survey them to see how many of them have issues if that would be convincing to anyone. However, I think the facts are pretty well established and ultimately it's a decision as to whether or not the maintainers want to account for the particularities of macOS's bundle validation process by loading the bundle within the async worker (and take on the additional maintenance burden).

Personally, I have my workaround, so I'm "fine". But I'm not a fan of macOS users that have have sufficient packages having an experience that leaves them with the opinion that Emacs has poor startup performance, or native compilation makes things worse, etc. Yes, those are narrowly-informed opinions, but I'm sure many users would not take the time to compare their startup performance to other OS's and/or to find this thread to better understand the depths of the problem. Instead, they'll just have a bad taste and deal with it every time they install a new version of Emacs.

Thanks,

Aaron