Re: Suppressing native compilation (short and long term)

[Eli Zaretskii <eliz@gnu.org>]

> From: Sean Whitton <spwhitton@spwhitton.name>
> Cc: Rob Browning <rlb@defaultvalue.org>,  monnier@iro.umontreal.ca,
>   david@tethera.net,  emacs-devel@gnu.org,  akrl@sdf.org
> Date: Sun, 02 Oct 2022 16:51:12 -0700
> 
> The point with battery consumption is not about running vs. standby.
> The issue is that while users expect that running apt-get will drain the
> battery, they expect that once apt-get is done, the only battery-hungry
> processes are ones they start themselves.

How does this work in practice?  I mean, what exactly do you mean by
"processes they start themselves"?  You mean, you know by heart each
Emacs command that invokes a subprocess, and avoid to invoke them all
unless the laptop is plugged in?  I don't believe this is practical,
because even "C-x C-f" invokes a a subprocess when you visit a file
under VCS (which I guess happens a lot to the likes of you and me).
And how can a person avoid all of those commands?  What am I missing?

> Laptop users typically avoid running apt-get without mains power
> plugged in.  If I do an 'apt-get upgrade' then afterwards my CPU
> will be churning away compiling addon packages, so I can't just
> unplug.

Did you actually try to see that "churning away" in practice, did you
look at the time this typically takes, the resources (battery and
otherwise) it consumes, etc.?  If so, can you share the data: how many
*.eln files were produced in how many minutes, how much battery did
that consume?

You see, I have my data, and it seems to indicate a very short period
of initial compilations for a modest consumption of resources.  (This
isn't a laptop, but I'm acutely aware of my system's load at all
times, and have it on the mode line, so I know what kind of
computation is going on during that time.)  The data I see here
doesn't look like it should be a problem for anyone, as long as files
are compiled only as they are used. In my case, for example, I see
maybe half a dozen *.eln files compiled after the initial startup.  I
expect to see that on any machine where a user has steady usage
patterns -- the compilation flats out very quickly.  I cannot imagine
how will your CPU churn out for any significant time after an upgrade.
A typical compilation of a single .el file is usually very fast,
exceptions are extremely rare.  And I barely notice the effect of that
on system responsiveness.

So I could imagine that many people perhaps base these judgments on
something they didn't actually try, but just imagined to themselves,
and imagined incorrectly, or based their opinions on some other
compilations of different languages in different environments.

I urge people to actually try this and see what it does, before making
up your minds.