Re: Deferring native compilation finalization until idle

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

> Eli Zaretskii <[email protected]> writes:
>
> > There's no hanging.  The JIT native-compilation is run in a separate
> > process, which is asynchronous to the main Emacs process.
>
> Maybe this is a terminology mistake on my part, but I would describe
> non-responsiveness to input "hanging" regardless of cause (e.g., saturated
> CPU cores).
>
> > So if you see any hang-like behavior, or "hiccups", I can only
> > explain them by your system having insufficient CPU resources for
> > handling the asynchronous processes without a visible performance
> > degradation.
>
> I don't think this is the case for reasons explained below; I have plenty
> of underutilized CPU cores when the problem behavior is occurring.
>
> > If that is the root cause, I can suggest fiddling with the value of
> > native-comp-async-jobs-number. Its default value of zero means Emacs
> > will launch as many async compilation jobs as half the number of
> > execution units your system has. You can try using values that are
> > smaller, like 1 or 2, to control how many async compilation jobs are
> > launched concurrently.
>
> Thank you, I think that was mentioned early in the thread and I forgot
> to test it—my bad.
>
> When setting `native-comp-async-jobs-number' to 1 or 2 it feels more like
> hiccups rather than hangs, with each "hiccup" lasting maybe on the order of
> 100 to 200 ms, every few seconds. These intermittent hiccups then continue
> for some time before eventually stopping. My (very!) uninformed guess on
> why this occurs is that this is just spreading out the big-long-hiccup that
> I was experiencing as each JIT compilation finishes more or less serially,
> rather than them all finishing at once and thus getting loaded in one big
> batch.
>
> >> When using my normal config and attempting to edit my init file with
> >> a clear cache I get about a ten second hang. Using the patch added
> >> to etc/PROBLEMS completely alleviates the problem and is a /massive/
> >> improvement.
> >
> > If that is what solves the problem for you, then it is something
> > specific to macOS and completely unrelated to JIT compilation: it is
> > due to macOS validation of a shared library when it is first loaded.
>
> My understanding is that the problem is right after the JIT compilation,
> when the library for the compiled file gets loaded. Does that seem accurate?
>
> > That's why we added that item to PROBLEMS, and if that is the solution
> > for you, I don't really understand what you are asking us to do more
> > here.
>
> Sorry if I wasn't clear—I think the solution in PROBLEMS is something that
> should be installed properly (implementation details notwithstanding). I
> only found this thread by chance as I never even imagined that this
> behavior isn't the norm, and I think that's the case for most macOS users
> (granted this is an assumption, but given that I can reproduce this from
> `emacs -Q' and I've had this issue across computers, I think it's a fair
> one).
>
> I do know there are some other macOS users on #emacs and I'm happy to do
> some surveying to see if the problem is truly widespread, if that would
> help.
>

I pretty much live in Emacs on macOS and this is a non-issue, IME.  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.

You did not elaborate on how you start your Emacs sessions.  You may want
to run the bundle from nextstep/Emacs.app rather than running the binary
directly to benefit from the bundle.