Re: Suppressing native compilation (short and long term)

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> FWIW, during the stealth jit-lock discussion, several people mentioned the
>> battery impact.
> Yes.  And jit-stealth is different, in that it takes a much longer
> time for it to become quiet, because it works in small chinks, and
> only when Emacs is actually idle.  JIT native-compilation is much
> faster, and also uses several execution units of the CPU in parallel.

Indeed, it's quite different.  I think even more important than the
above is the fact that it's a one-time thing only (for typical use cases
at least), whereas the jit-lock-stealth cost was paid over and over
again after every buffer modification.

>> And the issue is not subprocesses per se, but it's extra processing that
>> happens outside of the control of the user.
> How do you mean "outside of the control of the user"?  The user causes
> it by loading a feature.

When a user loads a feature, this request doesn't say explicitly "and
native compile the file".  And there is no direct way to "just load this
package without compiling it".  So the compilation is not really under
the control of the user.

I don't think users know, when they load a feature, if it's the first
time they loaded this feature in this version of Emacs, so by and large
they can't predict when the compilation does happen.

To be clear: I don't think it's a problem.  I just think it's part of
the reason for the reaction.

> How is that different from any other command that uses a subprocess
> under the hood?

It's different in that for those other commands, the users cannot get
the result they want without running that subprocess, so even if they're
not fully aware of it, they do have some vague idea it's inevitably
going to happen.

In contrast, the compilation is not indispensable, (so much so that the
past it never happened).

>> Probably not, no.  It's likely mostly a question of perception, so if we
>> could make it completely invisible the "problem" would disappear :-)
>> But the fact that lazy native compilation tends to pop up warnings (and
>> to make matters worse, it does so ... without warning) makes it very
>> much visible instead.
>
> On my system, I don't see any warnings.

That's presumably because you stick to the bundled packages (where we've
managed to keep a "no compilation warnings" state for the last few
years) or the few third party packages which are careful enough to
eliminate all warnings.

The rise of ELPA has removed most of the cases where native compilation
will miscompile files (because ELPA forces the .el files to be compiled
in a "standard" way rather than using ad-hoc Makefile rules which the
native compiler cannot and does not try to reproduce), but compilation
warnings are still very common (the situation is improving, tho, and
arguably the warnings popping up out of the blue during lazy native
compilation may prove to be a good way to convince more package authors
to clean up their act).


        Stefan