bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Andy Moreton
Subject: bug#46494: 28.0.50; [native-comp] Problems with async background compile
Date: Tue, 16 Mar 2021 20:10:16 +0000
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (windows-nt)

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.

    AndyM






reply via email to

[Prev in Thread] Current Thread [Next in Thread]