bug#65250: 30.0.50; "C-h f" is much slower on the master branch

[Andrea Corallo]

Andrea Corallo <acorallo@gnu.org> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: Andrea Corallo <acorallo@gnu.org>
>>> Cc: 65250@debbugs.gnu.org
>>> Date: Mon, 14 Aug 2023 10:51:46 -0400
>>>
>>> Eli Zaretskii <eliz@gnu.org> writes:
>>>
>>> > So I think the patch I presented in my original report is exactly what
>>> > is needed here: the problem only happens in builds without
>>> > native-compilation, and in that case there's no reason whatsoever to
>>> > call comp-function-type-spec.  (And builds from a release tarball will
>>> > not see that problem, since the tarball comes with byte-compiled
>>> > comp.el and comp-cstr.el.)
>>> >
>>> > Do you agree?
>>>
>>> I certainly do.  Thanks for the anylysis and the patch!
>>
>> Installed.
>>
>> Btw, why aren't comp.el and comp-cstr.el byte-compiled in a build
>> without native-compilation?  That's probably a bug in itself: we
>> generally byte-compile all the *.el files, even those that are not
>> relevant to the configuration being built.
>
> That's a good question, I'll have a look probably tomorrow.

Thinking better about it I guess the original rational behind was me
trying to minimize the impact of the original native-comp patch on
Emacs.

The following patch should do what we want, I'll test it as soon as I've
time before pushing it.

diff --git a/lisp/Makefile.in b/lisp/Makefile.in
index 5af2168a827..c4dd1e7a1f3 100644
--- a/lisp/Makefile.in
+++ b/lisp/Makefile.in
@@ -351,11 +351,7 @@ .PHONY:
 # TARGETS is set dynamically in the recursive call from 'compile-main'.
 # Do not build comp.el unless necessary not to exceed max-lisp-eval-depth
 # in normal builds.
-ifneq ($(HAVE_NATIVE_COMP),yes)
-compile-targets: $(filter-out ./emacs-lisp/comp-cstr.elc,$(filter-out 
./emacs-lisp/comp.elc,$(TARGETS)))
-else
 compile-targets: $(TARGETS)
-endif

 # Compile all the Elisp files that need it.  Beware: it approximates
 # 'no-byte-compile', so watch out for false-positives!