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

Previous Next

Full log

Message #35 received at 65250 <at> debbugs.gnu.org (full text, mbox):

From: Andrea Corallo <acorallo <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 65250 <at> debbugs.gnu.org
Subject: Re: bug#65250: 30.0.50; "C-h f" is much slower on the master branch
Date: Wed, 16 Aug 2023 04:37:36 -0400

Andrea Corallo <acorallo <at> gnu.org> writes:

> Andrea Corallo <acorallo <at> gnu.org> writes:
>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>>>> From: Andrea Corallo <acorallo <at> gnu.org>
>>>> Cc: 65250 <at> debbugs.gnu.org
>>>> Date: Mon, 14 Aug 2023 10:51:46 -0400
>>>>
>>>> Eli Zaretskii <eliz <at> 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!

Okay I pushed 2eaf1e3efca to always byte-compile native comp related
files also on non native builds.

Also thinking better about it, I think if this fix is sufficient to make
C-h f sufficiently fast in your test conditions we should revert
545f95d1a32.

Before installing it, even in non native builds, C-h f was showing the
type for functions listed in `comp-known-type-specifiers'.  I completely
forgot about this aspect reviewing the patch the other day apologies.

WDYT

  Andrea

Previous Next

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