Re: Deferring native compilation finalization until idle

On Sat, Jul 25, 2026 at 12:14 PM Aaron Jensen <[email protected]> wrote:

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

From first principles, what package is waiting to be built in the eln-cache
that Emacs is waiting for that prevents input?  AFAIK, the byte code is
first loaded and available to run and only then replaced on-the-fly when
native code is produced without error to replace it in the symbol's
function cell.

>