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

Previous Next

Full log

View this message in rfc822 format

From: Andrea Corallo <akrl <at> sdf.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 46256 <at> debbugs.gnu.org, andrewjmoreton <at> gmail.com, pipcet <at> gmail.com
Subject: bug#46256: [feature/native-comp] AOT eln files ignored if run from build tree
Date: Sun, 07 Mar 2021 19:05:18 +0000

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Andrea Corallo <akrl <at> sdf.org>
>> Cc: pipcet <at> gmail.com, 46256 <at> debbugs.gnu.org, andrewjmoreton <at> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.