[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Merging native-comp and pgtk
From: |
Lars Ingebrigtsen |
Subject: |
Re: Merging native-comp and pgtk |
Date: |
Sat, 13 Feb 2021 15:58:45 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
Stefan Monnier <monnier@iro.umontreal.ca> writes:
> There are some important differences between compiling to byte-code and
> compiling to native-code:
>
> - Compiling to byte-code is not transparent. The resulting code may
> behave differently in the two cases, there are questions like
> `load-prefer-newer`, the compilation itself is useful to get feedback
> via warnings (or even failures), the compilation can also have all
> kinds of side-effects (like an `eval-when-compile` which triggers
> compilation of something else...), the `load-history` will tell you
> which of .el or .elc you loaded, ...
.eln isn't fully transparent either -- you get different backtraces etc
from compiled code than byte-compiled code, for instance.
> - Compilation of byte-code is fast.
That's the main point for not switching it on, I guess.
> - Byte-code enjoys backward compatibility.
Very limited backwards compatibility -- we've introduced new byte codes
in Emacs 28, for instance. It's not a goal, but when it happens it's
nice.
Byte-code enjoys sideways compatibility, though -- one can use the same
.elc files on both ARM and AMD systems, but that's definitely not true
for .eln files. But... I'm not sure that's much of a consideration
either -- the rest of Emacs has to be built for a specific architecture,
so...
> None of those apply to native-code compilation. On an under-powered
> machine like a BananaPi byte-code compilation of the whole of Emacs
> takes quite a while (order of magnitude around 1h). It's a pain but
> it's bearable. For native-code compilation the order of magnitude is
> a whole day, which I don't find bearable, especially since all those
> .eln files need to be rebuilt as soon as I have recompiled a new
> `temacs`!
Oh, they have to be? I didn't know that. Why? :-)
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
- Re: Merging native-comp and pgtk, (continued)
- Re: Merging native-comp and pgtk, Andrea Corallo, 2021/02/14
- Re: Merging native-comp and pgtk, Stefan Kangas, 2021/02/14
- Re: Merging native-comp and pgtk, Andrea Corallo, 2021/02/14
- Re: Merging native-comp and pgtk, Óscar Fuentes, 2021/02/14
- Re: Merging native-comp and pgtk, Andrea Corallo, 2021/02/15
- Re: Merging native-comp and pgtk, Stefan Monnier, 2021/02/13
- Re: Merging native-comp and pgtk, Eli Zaretskii, 2021/02/13
- Re: Merging native-comp and pgtk, Dmitry Gutov, 2021/02/13
- Re: Merging native-comp and pgtk, Eli Zaretskii, 2021/02/13
- Re: Merging native-comp and pgtk, Stefan Monnier, 2021/02/13
- Re: Merging native-comp and pgtk,
Lars Ingebrigtsen <=
- Re: Merging native-comp and pgtk, Andrea Corallo, 2021/02/14
- Re: Merging native-comp and pgtk, Andrea Corallo, 2021/02/14
- Re: Cleaning out old X11 toolkits?, Eli Zaretskii, 2021/02/12
- Re: Cleaning out old X11 toolkits?, martin rudalics, 2021/02/13
- Re: Cleaning out old X11 toolkits?, Eli Zaretskii, 2021/02/13
- Re: Cleaning out old X11 toolkits?, martin rudalics, 2021/02/13
- Re: Cleaning out old X11 toolkits?, Robert Pluim, 2021/02/14
- Re: Cleaning out old X11 toolkits?, Eli Zaretskii, 2021/02/14
- Re: Cleaning out old X11 toolkits?, Robert Pluim, 2021/02/15
- Re: Cleaning out old X11 toolkits?, Eli Zaretskii, 2021/02/15