Re: Deferring native compilation finalization until idle

On Sat, Jul 25, 2026 at 8:39 AM, Perry Fraser < [email protected] > wrote:

> 
> 
> 
> Stéphane Marks < shipmints@ gmail. com ( [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 (
>> 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.

Aaron