GNU bug report logs - #46494
28.0.50; [native-comp] Problems with async background compile

Previous Next

Full log

View this message in rfc822 format

From: Andy Moreton <andrewjmoreton <at> gmail.com>
To: 46494 <at> debbugs.gnu.org
Subject: bug#46494: 28.0.50; [native-comp] Problems with async background compile
Date: Tue, 16 Mar 2021 20:10:16 +0000

On Tue 16 Mar 2021, Eli Zaretskii wrote:

>> Cc: 46494 <at> 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 <at> 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.

    AndyM

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.