Re: Deferring native compilation finalization until idle

On Sat, Jul 25, 2026 at 11:56 AM Aaron Jensen <[email protected]> wrote:

> On Sat, Jul 25, 2026 at 8:39 AM, Perry Fraser <[email protected]> wrote:
>
>> Stéphane Marks <[email protected]> writes:
>>
>> I pretty much live in Emacs on macOS and this is a non-issue, IME.
>>
>> Are you able to reproduce the behavior I described when starting with
>> an empty config and a custom eln cache path in your early-init.el?
>> (I found it especially obvious when launching M-x gnus, hitting m
>> to compose a message, and then typing.)
>>
>> I also assume you aren’t doing anything odd like running with SIP
>> disabled.
>>
>>
> What Eli said correctly describes macOS behavior and how to deal
>> with it. If you use an Emacs build that follows the “rules” and is
>> installed as a bundle as
>> https://github.com/jimeh/emacs-builds/releases do, you should not
>> see any “hangs.” A couple of days ago, I installed a new nightly
>> jimeh bundle which includes prebuilt native modules and recompiled
>> all external modules asynchronously just fine and with no delays.
>> Restarts are nearly instantaneous. If you are not running from a
>> bundle that macOS can “bless,” then you may experience delays.
>>
>> When launching a bundle downloaded from there by double-clicking the
>> .app I still experience the same behavior when my eln cache is empty,
>> as well as on my first launch without any eln cache shenanigans.
>>
>>
>
> I am also able to reproduce the issue with jimeh's build. It makes no
> difference for me. The only thing I can think of is that there's a
> difference in the number of packages loaded at startup time for Stéphane vs
> those that observe an issue.
>
> After starting Emacs fresh, I end up with 509 files in my eln-cache
> directory and there are significant main-thread stutters (to the point
> where Emacs is unusable for the first 10's of seconds after it starts the
> first time.
>
> I'm afraid that the notion that this is a CPU saturation problem is
> demonstrably false as well. When I was originally profiling this it was
> clear that it was the Emacs main thread that was being blocked while
> loading the new libraries. My suggested change was to move the first load
> to actually be asynchronous. This allows it to *actually* become a CPU
> saturation problem if it still occurs. As is stands now, it is effectively
> moving this relatively long-running, blocking task, to the Emacs main
> thread. How frequently it happens depends on how quickly you compile your
> eln files, meaning how many parallel instances you use.
>
> The Emacs main event loop is not impacted by asynchronous native
>> compilations so I can't say what is preventing your Emacs from processing
>> input keys.  The only explanation I have is that macOS itself is doing
>> precisely the thing that etc/PROBLEMS suggests a workaround for and which
>> the jimeh builds use:
>>
>>   codesign --force --sign - \
>>       --entitlements macos-disable-library-validation.entitlements \
>>       src/emacs
>>
>> Are you using that?
>>
>
> If the Jimeh build uses this, it didn't work for me. Regardless, this is
> exactly the thing that disables the security check macOS is doing. It is
> certainly a "workaround". And it does, in fact, prevent the stutter. If
> you're doing this (or your build is) and you're not seeing problems, that
> explains it completely. It seems somewhat strange to say "I'm already doing
> the workaround and I don't have the problem!", so I'm not sure exactly what
> you're getting at here. Without disabling validation, this *is a main
> thread problem* because the entirety of macOS compilation + validation is
> *not* done asynchronously.
>
> This is and likely always will be a macOS problem, but I struggle to see
> how it would be possible for *anyone* to not be affected without either
> applying one of the workarounds (as Stéphane/jimeh is doing) or by greatly
> reducing async count, which only lessens the problem, not eliminates it.
>

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?

>