bug#46494: 28.0.50; [native-comp] Problems with async background compile

[Andrea Corallo]

Andy Moreton <andrewjmoreton@gmail.com> writes:

> On Tue 16 Mar 2021, Eli Zaretskii wrote:
>
>>> Cc: 46494@debbugs.gnu.org
>>> Date: Tue, 16 Mar 2021 16:53:21 +0000
>>> From:  Andrea Corallo via "Bug reports for GNU Emacs,
>>>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>>> 
>>> Hi Andy,
>>> 
>>> is there anything left to be done for this bug?
>>
>> I'm not Andy (so let's wait for him to speak up), but here's my take.
>>
>> This bug had 3 parts:
>>
>>   a) Bug #46256 describes problems with AOT compiled native-comp emacs not
>>      finding prebuilt .eln files when built for mingw64 64bit on Windows.
>>
>>      As a result, emacs complains with an echo area warning for every .eln
>>      file that it cannot find in the expected location.
>>
>>      The stream of frequent warnings that causes make emacs mostly
>>      unresponsive to user input.
>>
>>   b) The "background" async compilation of .eln files is CPU intensive and
>>      somewhat slow. The default settings run a compile on every available
>>      core, which is unfriendly for other workloads running on the same
>>      machine.
>>
>>      It would be helpful to users to have a command to show the state of
>>      the async background compilation, including the running compile
>>      processes and the queue of pending compilation requests.
>>
>>   c) Quitting emacs when async compilation processes are running sometimes
>>      causes crashes in the compile processes, which show the emacs abort
>>      dialog (once for each async process). The dialogs disappear after a
>>      short delay (presumably due to the parent emacs having exited).
>>
>> c) Has been solved.
>> b) doesn't seem to be a problem IME, we use half the cores, and
>>    there's a way to customize that number
>> a) I didn't see at all, so I think it's also solved.
>
>
> Eli's take is a good summary of the issues.
> (a) is fixed.
> (b) is a wish-list item that will help ordinary users understand what
> the compiler is doing.
> (c) is fixed.
>
> Given the epic length of the discussion in this bug, I think we should
> probably close this bug report, and open fresh ones for any other
> issues.
>
> The native branch has received attention from a wider group of testers
> over the last few weeks, and as a result is much more solid. Thanks to
> all concerned for much hard work.

Nice, I'm closing this then.

Thanks!

  Andrea