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

[Lynn Winebarger <owinebar@gmail.com>]

[-- 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 --]