bug#46256: [feature/native-comp] AOT eln files ignored if run from build tree

[Andrea Corallo]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andrea Corallo <akrl@sdf.org>
>> Cc: pipcet@gmail.com, 46256@debbugs.gnu.org, andrewjmoreton@gmail.com
>> Date: Sun, 07 Mar 2021 06:57:24 +0000
>> 
>> > Another idea I had related to this: since there seem to be stability
>> > issues with even the recent versions of libgccjit, we should perhaps
>> > automatically add a .el file whose native-compilation failed to the
>> > list in comp-deferred-compilation-deny-list, so that the same Emacs
>> > session won't try native-compilation of the same .el file again.
>> > WDYT?
>> 
>> Sounds good, will do.
>
> Thanks.
>
>> > (Btw, the "deferred" part in the name of the variable sounds redundant
>> > to me, since we always compile asynchronously, except during
>> > bootstrap, which has a separate variable anyway.)
>> 
>> Well we expose also `native-compile' to compile synchronously (IIRC
>> that's also what package.el does if asked).
>
> I guess I'm confused: what's the difference between native-compile and
> the deferred compilation?  I though the deferred compilation just uses
> native-compile.  Or is there a different command for that?

We have two API entries for native compilation: `native-compile'
(synchronous) and `native-compile-async' (indeed asynchronous).

Deferred compilation is the mechanism to trigger automatically an async
native compilation (through `native-compile-async') for bytecodes being
loaded when the native code is not present (+ have the hotswap performed
when finished native compiling).

>> > A data point: subr-x.elc is 16247 bytes, whereas the corresponding
>> > .eln file (for 32-bit wide-int architecture) is 90631 bytes, a 5.5
>> > factor.
>> >
>> > If I look at the file with 'size', I get the following numbers:
>> >
>> >    text    data     bss     dec     hex filename
>> >   63951     788   24784   89523   15db3 subr-x-02dfef32-17faeb1d.eln
>> 
>> What's the size of the corresponding .elc ?
>
> See above: 16247 bytes.

Sorry for the sloppy answer this morning I was rushing :/ Looking at it
my subr-x.eln is pretty much big the same (the factor depends on the
single file).  I believe in general bytecode is a more compact
representation than native code.

  Andrea