bug#56988: Add call-interactively to "never optimize" list for native compilation

bug#56988: Add call-interactively to "never optimize" list for native compilation

[Lynn Winebarger]

[-- Attachment #1: Type: text/plain, Size: 456 bytes --]

Version 28.1:
Since dumping an Emacs with ~500 core libraries in addition to the 100+
from loadup (596 NCUs in the dump), I noticed huge numbers of async jobs
compiling trampolines for call-interactively.  Adding call-interactively -
and funcall-interactively for good measure - to the customization variable
for functions to never optimize, as well as to the hard-coded list in
advice--add-function, then recompiling and dumping resolved the issue.

Lynn

[-- Attachment #2: Type: text/html, Size: 573 bytes --]

bug#56988: Add call-interactively to "never optimize" list for native compilation

[Andrea Corallo]

Lynn Winebarger <owinebar@gmail.com> writes:

> Version 28.1:
> Since dumping an Emacs with ~500 core libraries in addition to the 100+ from loadup (596 NCUs in the dump), I noticed
> huge numbers of async jobs compiling trampolines for call-interactively.  Adding call-interactively - and
> funcall-interactively for good measure - to the customization variable for functions to never optimize, as well as to the
> hard-coded list in advice--add-function, then recompiling and dumping resolved the issue.

Hi Lynn,

I think we want to keep on optimizing `call-interactively' as changing
this policy this could have a negative performance impact in certain
scenarios.

Perhaps should be investigated why on the process you are engineering
this is happening, and modify it so that only one trampoline is
compiled.

Best Regards

  Andrea

bug#56988: Add call-interactively to "never optimize" list for native compilation

[Lynn Winebarger]

[-- Attachment #1: Type: text/plain, Size: 1806 bytes --]

On Fri, Aug 5, 2022, 6:07 AM Andrea Corallo <akrl@sdf.org> wrote:

> Lynn Winebarger <owinebar@gmail.com> writes:
>
> > Version 28.1:
> > Since dumping an Emacs with ~500 core libraries in addition to the 100+
> from loadup (596 NCUs in the dump), I noticed
> > huge numbers of async jobs compiling trampolines for
> call-interactively.  Adding call-interactively - and
> > funcall-interactively for good measure - to the customization variable
> for functions to never optimize, as well as to the
> > hard-coded list in advice--add-function, then recompiling and dumping
> resolved the issue.
>
> Hi Lynn,
>
> I think we want to keep on optimizing `call-interactively' as changing
> this policy this could have a negative performance impact in certain
> scenarios.
>
> Perhaps should be investigated why on the process you are engineering
> this is happening, and modify it so that only one trampoline is
> compiled.


Isn't call-interactively only used in the context of requesting user
input?  That would seem unlikely to benefit from optimization.
Something in one those additional core libraries being dumped is adding
advice to call-interactively.  One of the ways it started is by opening
customize on a group that autoloads a library that hasn't been native
compiled.  That starts the async process for the compiler.  This will
happen just running emacs with whatever library is advising
call-interactively in a problematic way in the dump.  It's not part of my
build process unless I use one of those builds with the additional
libraries as the compiler.
I'm noting it as a bug because it will bite anyone who includes these
additional libraries in the dump as a regular user, not because it impacts
my build process.  I know that's not frequently the case now, but it should
be eventually.

Lynn

[-- Attachment #2: Type: text/html, Size: 2398 bytes --]

bug#56988: Add call-interactively to "never optimize" list for native compilation

[Lars Ingebrigtsen]

Lynn Winebarger <owinebar@gmail.com> writes:

> Isn't call-interactively only used in the context of requesting user
> input?  That would seem unlikely to benefit from optimization.

Some interactive specs are pretty involved, and definitely benefit from
being compiled, so we're not going to stop doing that.

bug#56988: Add call-interactively to "never optimize" list for native compilation

[Lynn Winebarger]

[-- Attachment #1: Type: text/plain, Size: 608 bytes --]

On Fri, Aug 5, 2022, 8:18 AM Lars Ingebrigtsen <larsi@gnus.org> wrote:

> Lynn Winebarger <owinebar@gmail.com> writes:
>
> > Isn't call-interactively only used in the context of requesting user
> > input?  That would seem unlikely to benefit from optimization.
>
> Some interactive specs are pretty involved, and definitely benefit from
> being compiled, so we're not going to stop doing that.
>

Maybe it's only an issue in the "advice" case?  I can try removing it from
the customization variable but leave it in the hard coded list in the
advice--add-function code, if that would make a difference.

Lynn

[-- Attachment #2: Type: text/html, Size: 1287 bytes --]

bug#56988: Add call-interactively to "never optimize" list for native compilation

[Andrea Corallo]

Hello all,

I'm closing this bug as not reproducible on our codebase.

Best Regards

  Andrea

bug#56988: Add call-interactively to "never optimize" list for native compilation

[Lynn Winebarger]

[-- Attachment #1: Type: text/plain, Size: 779 bytes --]

On Fri, Aug 5, 2022, 8:18 AM Lars Ingebrigtsen <larsi@gnus.org> wrote:

> Lynn Winebarger <owinebar@gmail.com> writes:
>
> > Isn't call-interactively only used in the context of requesting user
> > input?  That would seem unlikely to benefit from optimization.
>
> Some interactive specs are pretty involved, and definitely benefit from
> being compiled, so we're not going to stop doing that.


Another possibility would be to ensure there is a standard pdmp file to use
for compiling, regardless of what is being used for the session calling the
compiler.  I know that is not an issue at the moment, but I'm the canary in
the coal mine for when dumping additional native compiled units.  That
feature is way too nice for someone to not get it in the trunk at some
point.

Lynn

[-- Attachment #2: Type: text/html, Size: 1302 bytes --]