Subject: bug#45751: [feature/native-comp] emacs keeps running 100% of CPU

From: Andrea Corallo <[email-masked]>
Date: Mon, 11 Jan 2021 10:25:59 +0000

Eli Zaretskii <[email-masked]> writes:

>> Date: Sun, 10 Jan 2021 20:14:53 +0000
>> Cc: [email-masked]
>> From: Andrea Corallo via "Bug reports for GNU Emacs,
>>  the Swiss army knife of text editors" <[email-masked]>
>> 
>> > Compiling
>> > /home/edouard/.emacs.d/elpa/color-theme-sanityinc-solarized-20200805.603/color-theme-sanityinc-solarized.el...
>> 
>> I see a similar issue with sanityinc-tomorrow.el, the compilation is way
>> slower than any other one but it completes eventually.  I guess is the
>> same issue you see and with sufficient RAM also sanityinc-solarized
>> should complete.
>> 
>> In case of of sanityinc-tomorrow I think is because of
>> `color-theme-sanityinc-tomorrow'.  This is a single function that after
>> macro expansion becomes enormous.
>> 
>> We need to make the compiler robust against these corner cases, I'll
>> have a look this week into adding some logic for that.
>
> Maybe we should have a "no-native-compile" cookie for these cases.
> After all, compiling a theme will not really speed up anything
> important, right?

Agreed, that's a good idea.

At the moment similar mechanisms are:

- Declare a function with (declare (speed -1)) will include the
  function in the .eln but in byte-code form.

- Have comp-speed to -1 as file variable in the source file should
  produce an eln containing only byte-code functions.

But yeah, a dedicated cookie is better because there's no point of
producing the .eln file at all for cases like this.

  Andrea