Re: [External] : Re: Native compilation

[Eli Zaretskii]

> Date: Tue, 11 Jan 2022 14:18:55 +0100
> From:  Emanuel Berg via Users list for the GNU Emacs text editor 
> <help-gnu-emacs@gnu.org>
> 
> Eli Zaretskii wrote:
> 
> >>>> Thanks, you mean not to compile it natively or not compile
> >>>> it at all?
> >>>
> >>> Natively.
> >> 
> >> Okay, it is interesting that you say so because didn't you
> >> use (?) to say that byte-compiling of the .emacs and
> >> supplemental files was disencouraged?
> >
> > I did, but how is that relevant to the issue at hand?
> 
> Because I would like to know if this new (?) attitude to a new
> thing - is that actually a new attitude, or is it an old
> attitude ("don't byte-compile your own Elisp") applied to
> a new thing? (native byte-compilation)

It is both.  I see little sense in compiling init files (except as a
method of finding bugs in them, which means you compile them and then
throw away the .elc files).  I see even less sense in natively
compiling them: you get all the "issues" caused by natively-compiled
ELisp, without any benefits.  So it's a net loss.  It follows that our
advice to users should be not to do something that results in net loss
for them.

> Or, if it indeed is a new attitude, what is the basis of
> that attitude? 

Natively-compiling Lisp files needs to make sure they are
self-contained, i.e. they don't depend on other Lisp files that are
not explicitly 'load'ed or 'require'd in them.  Otherwise you will
have warnings and errors during JIT native-compilation.

Natively-compiling Lisp files also means you'll need to have the
original Lisp files around, or else Emacs will refuse to load the .eln
file.  If you compress the source file, you need to have Emacs built
with decompression support (zlib), otherwise Emacs will refuse to load
the .eln file, claiming that the source isn't available.

Replacing the .eln file that is loaded into a running Emacs session is
"tricky" at best, because the *.eln files are actually shared
libraries in disguise, and your typical OS doesn't like it very much
when you delete a shared library that's in use.

Etc. etc. -- using the *.eln files comes at a price, so paying that
price when you get nothing in terms of performance is un-economical.
So my advice is not to do that.

> > Because the gains will be null and void.
> 
> OK, so that's the basis, but then I again ask, why are there
> gains doing this to the GNU Emacs (vanilla Emacs) Elisp, but
> not to the local (HOME) Elisp?

Because most of the code in a typical init file doesn't perform any
significant processing that can be sped up by natively-compiling it.

> Right, it doesn't look like it, either. So how do you natively
> byte-compile the file x.el?

By using one or more of special commands designed for that.

> >> That happens automatically when Emacs is run, after being
> >> configured --with-native-compilation [1], and it only
> >> affects GNU Emacs Elisp, right?
> >
> > What is "that" in this case?
> 
> Native byte-compilation of GNU Emacs (vanilla Emacs) Elisp.

It happens automatically when Emacs loads a .elc file whose .el file
can be found in the usual places, yes.

> >> Or what about [M]ELPA Elisp, that natively byte-compiled
> >> as well?
> >
> > What do you mean by "MELPA Elisp"?
> 
> The Elisp you get from ELPA and MELPA and possibly other
> places with the package manager.

Same thing.  The source of the Lisp code doesn't matter (of course).

> >> If so, even more so, then why not all Elisp?
> >
> > Why not what?
> 
> _If_ there is an advantage, and I agree it is, both in theory
> and in practice, to natively byte-compile the GNU Emacs
> (vanilla Emacs) Elisp, then how can it be that "the gains will
> be null and void" to do the same with the local (HOME) Elisp?

Most of the Lisp code you load does perform some processing that can
be sped up.  Of course, there are exceptions, but on the average
compiling them produces tangible gains.  Not so with init files.