Re: Suppressing native compilation (short and long term)

[Sean Whitton]

Hello,

On Mon 03 Oct 2022 at 07:19PM +03, Eli Zaretskii wrote:

>> 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?

Native compilation is significantly more CPU intensive than any of these
other things, though.

> 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.

I have actually tried it, for more than a year now, but admittedly I do
not have hard data.  Thank you for sharing yours.

-- 
Sean Whitton