Re: Suppressing native compilation (short and long term)

[Eli Zaretskii]

> From: Rob Browning <rlb@defaultvalue.org>
> Cc: monnier@iro.umontreal.ca, david@tethera.net, emacs-devel@gnu.org,
>  akrl@sdf.org
> Date: Sat, 01 Oct 2022 15:42:06 -0500
> 
> My current expectation is that if it ends up being feasible, we'll
> probably want to treat the package-related .eln files like the .elc
> files, and build them during the package install.  For example,
> elpa-magit (the current magit add-on package) will want to generate both
> the .elc and .eln files for all of its .el files when its turn comes
> around during installs/upgrades.
> 
> I say that because if it's a single-user machine and the user invokes
> "apt install elpa-magit", I'd imagine they're doing that because they
> want to use magit, in which case it doesn't hurt to get the work out of
> the way up-front, and it might help in that all the work will be
> finished at once, so they won't incur costs (battery-consumption, etc.)
> later, when they might not expect or want it.  (Not a critical issue,
> possibly, but perhaps friendlier.)
> 
> And if it's a multi-user machine, with a lot of emacs users, at the
> moment I don't see any reason to want to compile the same file 50 times
> for 50 users (or even more than just once), incurring the attendant
> power and storage costs.

I don't think you should try to second-guess the user who installs a
package.  They could just want to study the sources, for example.

The native compilation is implemented as JIT capability for a reason.
We dicussed the various aspects of that for a long time before
deciding on what you see today.  My advice is not to reject that
without very good reasons (and those reasons should probably be
communicated to us when found), just because of some analogy with byte
compilation, as that analogy breaks on several levels.  By using
native compilation in its default JIT manner, you are basically using
Emacs as the upstream project meant it to be used, which means, among
others, that you don't need to fight an uphill battle against various
defaults and discover situations that no one expected to happen.

The reasons which you mention in favor of AOT native compilation don't
sound serious enough: I see no problem in having the compilation
happen only when it's needed in those cases.  Battery consumption
doesn't seem very relevant, because JIT compilation will happen when
the system is used, not when it sleeps.  And it is entirely not
guaranteed that by compiling everything you will save power in the
long run, because there are good chances you will be compiling stuff
that won't be used for a long time.  Without quantitative data of
long-term power usage on which to base the conclusions, I don't see
why you should a-priori assume that compiling everything from the
get-go should use less power.  Same goes for disk space by multiple
users.

All in all, I think JIT compilation strikes a good balance between
resources and their actual usage.  This also matches my personal
experience of using Emacs 28 with native compilation since day one: I
never had to look back on the decision not to use AOT compilation of
everything.

Of course, this is eventually your call.  But my recommendation is to
try to stick to the default behavior unless it causes actual (as
opposed to imaginary or presumed) problems, based on actual usage.