From unknown Sun Jun 22 04:14:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#65250: 30.0.50; "C-h f" is much slower on the master branch Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 12 Aug 2023 15:50:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 65250 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 65250@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.1691855349902 (code B ref -1); Sat, 12 Aug 2023 15:50:02 +0000 Received: (at submit) by debbugs.gnu.org; 12 Aug 2023 15:49:09 +0000 Received: from localhost ([127.0.0.1]:56671 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qUqrU-0000EU-MW for submit@debbugs.gnu.org; Sat, 12 Aug 2023 11:49:09 -0400 Received: from lists.gnu.org ([2001:470:142::17]:45812) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qUqrR-0000Dx-0J for submit@debbugs.gnu.org; Sat, 12 Aug 2023 11:49:06 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qUqrL-0000vS-9O for bug-gnu-emacs@gnu.org; Sat, 12 Aug 2023 11:48:59 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qUqrL-0004v2-14 for bug-gnu-emacs@gnu.org; Sat, 12 Aug 2023 11:48:59 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=Subject:To:From:Date:mime-version:in-reply-to: references; bh=25m7hNC6gWsPFXg9RoPKoGjItsEdM33lstymcMLBWDA=; b=MNX4mrRZenGlvU bO7/Z5VPyJu+G5f0S9T4iwbaXIPLvfQ5+X60e52ffJdfb3qkHpBaj9WGXdFX5FTqvnixVnC2HeGvr x+7WPuIhG5Nxt1YmhdTJDY0xjCNjU1lRf6BL7fMsTQ5tLGNx1l/DoSQcXJGQuSCiRF7X53ndO0aX9 Hh/13w6MO2ODhFSEZi9UWRrnCKjD+z4itSPueVNTw2/QhyhcZ480hLXn+5C4mhjz8/qQ8QkyWsuYm P54i3S81WV/lkFTUeIJx75opN8pe80QpCIYuuf2D+tyEfcpdxJ+ApMDgNxzycF4rk6KnBxpy/iRgc uCeMH37KFRDto0SHFppg==; Date: Sat, 12 Aug 2023 18:49:30 +0300 Message-Id: <838ragdzw5.fsf@gnu.org> From: Eli Zaretskii X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) To reproduce: emacs -Q C-h f dictionary-search RET (almost any other function will do, I think). This takes a whopping 6.6 sec of CPU on master, vs 2.4 sec on the emacs-29 branch. These are both unoptimized builds, but even so, 6.6 seconds of CPU time for looking up a doc string of a function is too much, I think. The patch below fixes the problem in a build without native-compilation, but won't help in a build with native-compilation. I wonder why comp-function-type-spec is so expensive? In GNU Emacs 30.0.50 (build 417, i686-pc-mingw32) of 2023-08-12 built on HOME-C4E4A596F7 Repository revision: d3dae88e6cc8118c875957ba0347be9599014b34 Repository branch: master Windowing system distributor 'Microsoft Corp.', version 5.1.2600 System Description: Microsoft Windows XP Service Pack 3 (v5.1.0.2600) Configured using: 'configure -C --prefix=/d/usr --with-wide-int --enable-checking=yes,glyphs 'CFLAGS=-O0 -gdwarf-4 -g3'' Configured features: ACL GIF GMP GNUTLS HARFBUZZ JPEG JSON LCMS2 LIBXML2 MODULES NOTIFY W32NOTIFY PDUMPER PNG RSVG SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XPM ZLIB Important settings: value of $LANG: ENU locale-coding-system: cp1255 Major mode: Lisp Interaction Minor modes in effect: tooltip-mode: t global-eldoc-mode: t eldoc-mode: t show-paren-mode: t electric-indent-mode: t mouse-wheel-mode: t tool-bar-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t line-number-mode: t indent-tabs-mode: t transient-mark-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t Load-path shadows: None found. Features: (shadow sort mail-extr emacsbug message mailcap yank-media puny dired dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068 epg-config gnus-util text-property-search time-date subr-x mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils rmc iso-transl tooltip cconv eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel dos-w32 ls-lisp disp-table term/w32-win w32-win w32-vars term/common-win touch-screen tool-bar dnd fontset image regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors frame minibuffer nadvice seq simple cl-generic indonesian philippine cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese composite emoji-zwj charscript charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp files window text-properties overlay sha1 md5 base64 format env code-pages mule custom widget keymap hashtable-print-readable backquote threads w32notify w32 lcms2 multi-tty move-toolbar make-network-process emacs) Memory information: ((conses 16 42844 17019) (symbols 48 6336 0) (strings 16 16702 3269) (string-bytes 1 401689) (vectors 16 9351) (vector-slots 8 147820 16098) (floats 8 23 25) (intervals 40 276 95) (buffers 896 10)) Here's the patch I promised: diff --git a/lisp/help-fns.el b/lisp/help-fns.el index fc8f431..bedc5a9 100644 --- a/lisp/help-fns.el +++ b/lisp/help-fns.el @@ -715,7 +715,8 @@ help-fns--signature (unless (and (symbolp function) (get function 'reader-construct)) (insert high-usage "\n") - (when-let* ((res (comp-function-type-spec function)) + (when-let* ((res (and (native-comp-available-p) + (comp-function-type-spec function))) (type-spec (car res)) (kind (cdr res))) (insert (format From unknown Sun Jun 22 04:14:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#65250: 30.0.50; "C-h f" is much slower on the master branch Resent-From: Andrea Corallo Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 12 Aug 2023 16:58:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65250 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 65250@debbugs.gnu.org Received: via spool by 65250-submit@debbugs.gnu.org id=B65250.16918594598000 (code B ref 65250); Sat, 12 Aug 2023 16:58:02 +0000 Received: (at 65250) by debbugs.gnu.org; 12 Aug 2023 16:57:39 +0000 Received: from localhost ([127.0.0.1]:56753 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qUrvm-00024y-N7 for submit@debbugs.gnu.org; Sat, 12 Aug 2023 12:57:38 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:54776) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qUrvj-00024k-Fh for 65250@debbugs.gnu.org; Sat, 12 Aug 2023 12:57:36 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qUrve-0001Ko-9c for 65250@debbugs.gnu.org; Sat, 12 Aug 2023 12:57:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To: From; bh=5chbDVtDA1+K/XLUBRZnoHhhD6b/Zq93BCQgsty8kIQ=; b=C3cezwNdju6cIPFdXXic 9Zf2FhXzz0YPQher/HNuvXHNajQE+10xj9Jp2V64EvwNsEvuYPoEl61dKIsDGCPYARip84NSaUUQO b6tEj4CCFQI+gPaMIbF+7KrJJzZ3zp3CoAvqeq1w25Z2z0VsZSP5GtilAVWnnxNsH1djXXbQWaVFa Ca83Nz2wYB66mfsMrtuex1+xXF9dZq2UUuRch+Dx41h14EOzDO9E70S8zqX3yj+fhCyfRYNfTrAbN PckBAnVCABzl3d05FjGso6Mgf0Q6mdUYDoJprxbmUv4LCYEAOmrUnbj79cIN7GVf6+BFfM1V7y7mI fv0EjrMUdVdF4w==; Received: from acorallo by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1qUrvb-0004Lh-FI; Sat, 12 Aug 2023 12:57:29 -0400 From: Andrea Corallo In-Reply-To: <838ragdzw5.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 12 Aug 2023 18:49:30 +0300") References: <838ragdzw5.fsf@gnu.org> Date: Sat, 12 Aug 2023 12:57:27 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: > To reproduce: > > emacs -Q > C-h f dictionary-search RET > > (almost any other function will do, I think). > > This takes a whopping 6.6 sec of CPU on master, vs 2.4 sec on the > emacs-29 branch. These are both unoptimized builds, but even so, > 6.6 seconds of CPU time for looking up a doc string of a function > is too much, I think. > > The patch below fixes the problem in a build without > native-compilation, but won't help in a build with native-compilation. > I wonder why comp-function-type-spec is so expensive? Hi Eli, can't look at this now, will do on Monday and report. Best Regards Andrea From unknown Sun Jun 22 04:14:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#65250: 30.0.50; "C-h f" is much slower on the master branch Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 12 Aug 2023 17:24:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65250 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Andrea Corallo Cc: 65250@debbugs.gnu.org Received: via spool by 65250-submit@debbugs.gnu.org id=B65250.169186099410776 (code B ref 65250); Sat, 12 Aug 2023 17:24:02 +0000 Received: (at 65250) by debbugs.gnu.org; 12 Aug 2023 17:23:14 +0000 Received: from localhost ([127.0.0.1]:56769 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qUsKX-0002nk-Ky for submit@debbugs.gnu.org; Sat, 12 Aug 2023 13:23:13 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:46836) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qUsKW-0002nU-Fa for 65250@debbugs.gnu.org; Sat, 12 Aug 2023 13:23:12 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qUsKR-00063k-AS for 65250@debbugs.gnu.org; Sat, 12 Aug 2023 13:23:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=/HMcYDQJJOryXQKWCYbf70ksojbODCR/F7yBxXDdOZ8=; b=RpMf5yDKB3Ok i9YH1ZHW+1oJsBd0s3ZplamQ97qcbWoUorSkrmIqfilZfGysNORmhiKVzpJJhDTfv6WTI81SICQdy J2e/MLbbKUsshtDrizyND29mI/Qo/SqYjNCvvGKbNAyvJZ/6AV455vZIknYrZSwyFp/ayp9qOjG9k UkdHToFoIjoIvv3t4mlXmyGJptZeBCOd1eNZGFFJlP3brikcZqUG85+uAP4gEqyzxbXIqdwOoH1G6 Jfbklj6HvGz/hNQE2jM93/SyW0lERRhWlkaBcfYKSxAY3UkOEO5lJHTKH/zKyXL9v8gqpSahTmzEP zPH/hkYQQsQRom24IYe2/g==; Date: Sat, 12 Aug 2023 20:23:39 +0300 Message-Id: <83350odvj8.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Andrea Corallo on Sat, 12 Aug 2023 12:57:27 -0400) References: <838ragdzw5.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Andrea Corallo > Cc: 65250@debbugs.gnu.org > Date: Sat, 12 Aug 2023 12:57:27 -0400 > > Eli Zaretskii writes: > > > To reproduce: > > > > emacs -Q > > C-h f dictionary-search RET > > > > (almost any other function will do, I think). > > > > This takes a whopping 6.6 sec of CPU on master, vs 2.4 sec on the > > emacs-29 branch. These are both unoptimized builds, but even so, > > 6.6 seconds of CPU time for looking up a doc string of a function > > is too much, I think. > > > > The patch below fixes the problem in a build without > > native-compilation, but won't help in a build with native-compilation. > > I wonder why comp-function-type-spec is so expensive? > > Hi Eli, > > can't look at this now, will do on Monday and report. Thanks, this is on master, so not very urgent. From unknown Sun Jun 22 04:14:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#65250: 30.0.50; "C-h f" is much slower on the master branch Resent-From: Andrea Corallo Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 14 Aug 2023 09:00:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65250 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 65250@debbugs.gnu.org Received: via spool by 65250-submit@debbugs.gnu.org id=B65250.169200358517808 (code B ref 65250); Mon, 14 Aug 2023 09:00:02 +0000 Received: (at 65250) by debbugs.gnu.org; 14 Aug 2023 08:59:45 +0000 Received: from localhost ([127.0.0.1]:32918 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qVTQP-0004d7-0l for submit@debbugs.gnu.org; Mon, 14 Aug 2023 04:59:45 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:42470) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qVTQN-0004ck-Gk for 65250@debbugs.gnu.org; Mon, 14 Aug 2023 04:59:44 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qVTQH-0007N8-Gn for 65250@debbugs.gnu.org; Mon, 14 Aug 2023 04:59:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To: From; bh=N7DonUhVQygwGqdhW5/Whm1dhVntwB8SldHIyvsFA2g=; b=U7VjNQ8c5HstVAqUDgkq 5usQt1DkRETGWIM3RgKrqoj0bZWxhgG0TWo1AWfpVkyMJDw5Hb0W9MYsbqL66KDFSRH2id9n9GZBH QvHs1MrXPfXal+L4Jzt4BLbc1eIGW78YuGDgkTvkf1jmUhY+nFCmiUkh56+R8XVefJZ2uP4QY/ser A584PHurqGX/Tfbl3bUlRX5CfmlVFkr8btQ5UCrW5CcVE/IKcZV6GWSBBP5QlAngfNxToGHMtee9Z GGqnXjD11wVD40S0fZhAl2x1eiSUI8QmOkkwY/vkmuhqqaQZEQdhNueeMcjN+o0wCIaOHjSsOImuY ksljeGhUGtNoOw==; Received: from acorallo by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1qVTPy-00030X-5B; Mon, 14 Aug 2023 04:59:25 -0400 From: Andrea Corallo In-Reply-To: <838ragdzw5.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 12 Aug 2023 18:49:30 +0300") References: <838ragdzw5.fsf@gnu.org> Date: Mon, 14 Aug 2023 04:59:18 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: > To reproduce: > > emacs -Q > C-h f dictionary-search RET > > (almost any other function will do, I think). > > This takes a whopping 6.6 sec of CPU on master, vs 2.4 sec on the > emacs-29 branch. These are both unoptimized builds, but even so, > 6.6 seconds of CPU time for looking up a doc string of a function > is too much, I think. > > The patch below fixes the problem in a build without > native-compilation, but won't help in a build with native-compilation. > I wonder why comp-function-type-spec is so expensive? Hi Eli, I'm failing to reproduce it, this is what I did on latest master: ~~~ CFLAGS='-g3 -O0' make bootstrap -j16 ./src/emacs -Q M-: (require 'dictionary) C-h f dictionary-search RET ~~~ The result is pretty much istantaneous on my machine. I guess I'm doing something different from what you did? Thanks Andrea From unknown Sun Jun 22 04:14:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#65250: 30.0.50; "C-h f" is much slower on the master branch Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 14 Aug 2023 12:20:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65250 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Andrea Corallo Cc: 65250@debbugs.gnu.org Received: via spool by 65250-submit@debbugs.gnu.org id=B65250.16920155623379 (code B ref 65250); Mon, 14 Aug 2023 12:20:02 +0000 Received: (at 65250) by debbugs.gnu.org; 14 Aug 2023 12:19:22 +0000 Received: from localhost ([127.0.0.1]:33114 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qVWXa-0000sQ-Hb for submit@debbugs.gnu.org; Mon, 14 Aug 2023 08:19:22 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:39428) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qVWXY-0000s4-Vj for 65250@debbugs.gnu.org; Mon, 14 Aug 2023 08:19:21 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qVWXT-0008Fz-P2 for 65250@debbugs.gnu.org; Mon, 14 Aug 2023 08:19:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=41BiKkTNBhzWWwh5LwyFCO5FQuqQaxO0hOSF5CoOgzw=; b=rBePG+NfYxvr YExagTwldfnCWsvhTHxhCBz3/+fwbu+vcv8lOWliHnzKLJG6fMBH0C1RsbjphXuM5FXP02AiFs/df GeP3WMU6Ixw2WeHLI4HjlPrH4OSxi50e9u7n2xMAaPXWSRndVnH6w8VDtpISkKjXJSXVr3x05fAlh yuKm4F3Yv61DVyDHyPkxOBuCY469AzKAph1DQMLSsLIZPsFZ+1l8f9UhIpEYkNZXez45aHZ7BA0C0 /SkZJgIiTl6dmO1Mq1rrxlDKIKXaWd8oNd259Luxns7iwY50MxpJkEzy1ssbCQbZnOw11P5CgTcuv 7Dcvn79lSbvFkYVYFTrQ/A==; Date: Mon, 14 Aug 2023 15:19:16 +0300 Message-Id: <83cyzpbyuz.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Andrea Corallo on Mon, 14 Aug 2023 04:59:18 -0400) References: <838ragdzw5.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Andrea Corallo > Cc: 65250@debbugs.gnu.org > Date: Mon, 14 Aug 2023 04:59:18 -0400 > > I'm failing to reproduce it, this is what I did on latest master: > > ~~~ > > CFLAGS='-g3 -O0' make bootstrap -j16 > > ./src/emacs -Q > > M-: (require 'dictionary) > > C-h f dictionary-search RET > > ~~~ > > The result is pretty much istantaneous on my machine. > > I guess I'm doing something different from what you did? My configuration was included with the report: 'configure -C --prefix=/d/usr --with-wide-int --enable-checking=yes,glyphs 'CFLAGS=-O0 -gdwarf-4 -g3'' Perhaps --enable-checking makes the difference? If even that doesn't show the problem, just time the above and compare with Emacs 29: it's possible that the command is much faster on your system, but the question is it significantly slower than Emacs 29? From unknown Sun Jun 22 04:14:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#65250: 30.0.50; "C-h f" is much slower on the master branch Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 14 Aug 2023 14:41:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65250 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: acorallo@gnu.org Cc: 65250@debbugs.gnu.org Received: via spool by 65250-submit@debbugs.gnu.org id=B65250.169202404427855 (code B ref 65250); Mon, 14 Aug 2023 14:41:01 +0000 Received: (at 65250) by debbugs.gnu.org; 14 Aug 2023 14:40:44 +0000 Received: from localhost ([127.0.0.1]:34111 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qVYkN-0007FC-HO for submit@debbugs.gnu.org; Mon, 14 Aug 2023 10:40:43 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:45606) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qVYkM-0007F0-Cr for 65250@debbugs.gnu.org; Mon, 14 Aug 2023 10:40:43 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qVYkH-00016x-6x for 65250@debbugs.gnu.org; Mon, 14 Aug 2023 10:40:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=Eskv0Jfq4GGj+XFk6KmAqJiZINUGN4hlbB0/xbbk6Lg=; b=WSzTQ1i996Yh jzfcV8TmykbYRTVlFJu7YoyqWe7/kQXDACO4iQUb9ayzBIlotjlGSeVIfQEXq1mbS8NcqkNvtrac5 WVOBRcYiJPEE1pFVUcdxe3Q+LlSI51IOAEpKrCuWhWgTp5r5UVmVxXdyZIQ6HkrTlFbGuO47h/xwv YDbgn9uPmbBE3h1+PZELvBwjMLhwQZsfNrZOJ0iinlfQfXc5uoFYqx/0rskc7HfAb+dohYPj2CwoX mdR2IWpmbMCusqF4kBj/QmirMWXWBLY6SjD/qH3lOveA83SU5NgWjUDcX4op30XI0SXnYx3Plqn10 Ezu5VyiN5euHIS0gV8KLIg==; Date: Mon, 14 Aug 2023 17:40:13 +0300 Message-Id: <835y5hbsc2.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <83cyzpbyuz.fsf@gnu.org> (message from Eli Zaretskii on Mon, 14 Aug 2023 15:19:16 +0300) References: <838ragdzw5.fsf@gnu.org> <83cyzpbyuz.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: 65250@debbugs.gnu.org > Date: Mon, 14 Aug 2023 15:19:16 +0300 > From: Eli Zaretskii > > 'configure -C --prefix=/d/usr --with-wide-int > --enable-checking=yes,glyphs 'CFLAGS=-O0 -gdwarf-4 -g3'' > > Perhaps --enable-checking makes the difference? > > If even that doesn't show the problem, just time the above and compare > with Emacs 29: it's possible that the command is much faster on your > system, but the question is it significantly slower than Emacs 29? It sounds like the problem is the packages that Emacs needs to load when comp-function-type-spec is called. If I set force-load-messages to t before invoking "C-h f", I see this in the *Messages* buffer: Loading help-fns... Loading cl-lib... Loading cl-loaddefs...done Loading cl-lib...done Loading help-mode...done Loading radix-tree...done Loading help-fns...done Loading thingatpt...done Loading dictionary... Loading dictionary-connection...done Loading external-completion...done Loading dictionary...done Loading lisp/emacs-lisp/comp.el (source)... Loading bytecomp...done Loading cl-extra...done Loading cl-macs... Loading gv...done Loading cl-macs...done Loading cl-seq...done Loading rx...done Loading subr-x...done Loading warnings... Loading icons...done Loading warnings...done Loading lisp/emacs-lisp/comp-cstr.el (source)... Loading pcase...done Loading lisp/emacs-lisp/comp-cstr.el (source)...done Loading derived...done Loading lisp/emacs-lisp/comp.el (source)...done Loading shortdoc... Loading text-property-search...done Loading shortdoc...done Note the loading of comp.el and comp-cstr.el -- we load their source files, not the *.elc files. That's because in a build without native compilation these two files are not byte-compiled. I think loading of these files, especially of comp.el, in source form is what slows down the command. I'm guessing your build was with native compilation? Because in such a build the "C-h f" command is indeed fast, especially after the requisite *.el files are all native-compiled (i.e. starting from the second Emacs invocation after the build). 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? From unknown Sun Jun 22 04:14:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#65250: 30.0.50; "C-h f" is much slower on the master branch Resent-From: Andrea Corallo Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 14 Aug 2023 14:52:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65250 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 65250@debbugs.gnu.org Received: via spool by 65250-submit@debbugs.gnu.org id=B65250.169202471529200 (code B ref 65250); Mon, 14 Aug 2023 14:52:01 +0000 Received: (at 65250) by debbugs.gnu.org; 14 Aug 2023 14:51:55 +0000 Received: from localhost ([127.0.0.1]:34127 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qVYvC-0007au-KD for submit@debbugs.gnu.org; Mon, 14 Aug 2023 10:51:54 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:56456) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qVYvA-0007ag-AP for 65250@debbugs.gnu.org; Mon, 14 Aug 2023 10:51:53 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qVYv5-0003Zq-2n for 65250@debbugs.gnu.org; Mon, 14 Aug 2023 10:51:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To: From; bh=WHlP5ZEsEczZ3MT5mcPMPcUfIJDxT8TKffSkCQIiQPA=; b=nwoKBZHLOPa5psF7xkWk IIv+SLTshf7g1OlHBPqL5CFQbZFJZzvzV0znZmusaYcC4pVp112eBZOneTg7AoDhdQ9rDGCYu7jqv 9j9Pa0hD8vfyxkp98NMxpfNy/CT8LPBmvqwfgu9H1xf+MiW9BJ6JmE3r+w5Cq8cRYHH5NVaJYT2vK tpghO888K/EW2dQ03zClc/tJkF/jD1/BPnjMoDoDPFTWytDUyV06cHdRp0gxu06Ru57CjrOiZkyeV PEZ0ki1TTNLvVmv6dr9I5zkMFIsJw4PFMy5AKf7aRET8X3WAVKbRzXRcn7E7/2bO2xBdH9WJPKO/Y vU9gKEddQLh2vw==; Received: from acorallo by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1qVYv4-0006xn-Ri; Mon, 14 Aug 2023 10:51:46 -0400 From: Andrea Corallo In-Reply-To: <835y5hbsc2.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 14 Aug 2023 17:40:13 +0300") References: <838ragdzw5.fsf@gnu.org> <83cyzpbyuz.fsf@gnu.org> <835y5hbsc2.fsf@gnu.org> Date: Mon, 14 Aug 2023 10:51:46 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: >> Cc: 65250@debbugs.gnu.org >> Date: Mon, 14 Aug 2023 15:19:16 +0300 >> From: Eli Zaretskii >> >> 'configure -C --prefix=/d/usr --with-wide-int >> --enable-checking=yes,glyphs 'CFLAGS=-O0 -gdwarf-4 -g3'' >> >> Perhaps --enable-checking makes the difference? >> >> If even that doesn't show the problem, just time the above and compare >> with Emacs 29: it's possible that the command is much faster on your >> system, but the question is it significantly slower than Emacs 29? > > It sounds like the problem is the packages that Emacs needs to load > when comp-function-type-spec is called. If I set force-load-messages > to t before invoking "C-h f", I see this in the *Messages* buffer: > > Loading help-fns... > Loading cl-lib... > Loading cl-loaddefs...done > Loading cl-lib...done > Loading help-mode...done > Loading radix-tree...done > Loading help-fns...done > Loading thingatpt...done > Loading dictionary... > Loading dictionary-connection...done > Loading external-completion...done > Loading dictionary...done > Loading lisp/emacs-lisp/comp.el (source)... > Loading bytecomp...done > Loading cl-extra...done > Loading cl-macs... > Loading gv...done > Loading cl-macs...done > Loading cl-seq...done > Loading rx...done > Loading subr-x...done > Loading warnings... > Loading icons...done > Loading warnings...done > Loading lisp/emacs-lisp/comp-cstr.el (source)... > Loading pcase...done > Loading lisp/emacs-lisp/comp-cstr.el (source)...done > Loading derived...done > Loading lisp/emacs-lisp/comp.el (source)...done > Loading shortdoc... > Loading text-property-search...done > Loading shortdoc...done > > Note the loading of comp.el and comp-cstr.el -- we load their source > files, not the *.elc files. That's because in a build without native > compilation these two files are not byte-compiled. I think loading of > these files, especially of comp.el, in source form is what slows down > the command. Maybe, comp-cstr.el might have even a bigger part. > I'm guessing your build was with native compilation? Yes, I was experimenting just now (and failing to reproduce) with CFLAGS='-O0 -gdwarf-4 -g3' ./configure --without-x --with-native-compilation=yes --prefix='/home/andcor03' --enable-checking=yes,glyphs --with-wide-int > Because in such > a build the "C-h f" command is indeed fast, especially after the > requisite *.el files are all native-compiled (i.e. starting from the > second Emacs invocation after the build). Ah right! now it's all clear! > 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! Andrea From unknown Sun Jun 22 04:14:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#65250: 30.0.50; "C-h f" is much slower on the master branch Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 14 Aug 2023 15:12:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65250 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Andrea Corallo Cc: 65250@debbugs.gnu.org Received: via spool by 65250-submit@debbugs.gnu.org id=B65250.169202590931163 (code B ref 65250); Mon, 14 Aug 2023 15:12:02 +0000 Received: (at 65250) by debbugs.gnu.org; 14 Aug 2023 15:11:49 +0000 Received: from localhost ([127.0.0.1]:34180 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qVZES-00086Z-W1 for submit@debbugs.gnu.org; Mon, 14 Aug 2023 11:11:49 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:32822) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qVZER-00086N-Bx for 65250@debbugs.gnu.org; Mon, 14 Aug 2023 11:11:47 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qVZEL-0008IV-U5 for 65250@debbugs.gnu.org; Mon, 14 Aug 2023 11:11:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=Q850clcvhaw/MPmx9aDm3tLiiDBxSiJpLcXUV002WrI=; b=SwD+2mpFYoR1 uhKzNSsNPxmdyOVffRW8S9QFA301kYAVg+20dukuYEeUtw7XYETdqeuZR04B44dcYNZLjbc6thLBN aJJzY4Sa/V1GwGpZbWonH2zDafZdLAid4WcHkZ3h6aVWxW5fbYWJ3DyOJZCZ0hE//vLRb9jF2KCmq v6PD0BVEooazB9ef2VxS3O3agsK50D9pl1OKnei9DWmRn/tjGUHyQjvgF8haaN1lqevJDCfzUKQAQ i7ovKZIlx5xqnR0thx6llkOT/Tnwru0FDyWg4owHvuG25/yJMIkbTXBMnCtbvr6nGZY8fRERosdYw FJhV1yJ5v8BLAYn/zmC/rg==; Date: Mon, 14 Aug 2023 18:11:42 +0300 Message-Id: <834jl1bqvl.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Andrea Corallo on Mon, 14 Aug 2023 10:51:46 -0400) References: <838ragdzw5.fsf@gnu.org> <83cyzpbyuz.fsf@gnu.org> <835y5hbsc2.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Andrea Corallo > Cc: 65250@debbugs.gnu.org > Date: Mon, 14 Aug 2023 10:51:46 -0400 > > Eli Zaretskii 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. From unknown Sun Jun 22 04:14:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#65250: 30.0.50; "C-h f" is much slower on the master branch Resent-From: Andrea Corallo Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 14 Aug 2023 15:20:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65250 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 65250@debbugs.gnu.org Received: via spool by 65250-submit@debbugs.gnu.org id=B65250.16920263909499 (code B ref 65250); Mon, 14 Aug 2023 15:20:02 +0000 Received: (at 65250) by debbugs.gnu.org; 14 Aug 2023 15:19:50 +0000 Received: from localhost ([127.0.0.1]:34199 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qVZMD-0002T9-MK for submit@debbugs.gnu.org; Mon, 14 Aug 2023 11:19:49 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:51180) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qVZMC-0002Sx-Dp for 65250@debbugs.gnu.org; Mon, 14 Aug 2023 11:19:49 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qVZM7-0001Gl-29 for 65250@debbugs.gnu.org; Mon, 14 Aug 2023 11:19:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To: From; bh=27mmI5bvjG3JO287nE8oGu6puzPdo1kQnbUjhlvITNE=; b=FhyhbZYSuqUjMpcKpQPj zD/wBKAa73e9WvoC4EDjFhUmvg+1hDCtzWvMDG7Aa1+q2WfADhrL0G+Kp3Gcn3qu2WMPpBea067B5 3syhxjX9tw4qJRuIk6ucN6mcydHLnq0tz37rF6Bby4IzGHhwoPaAVE1usVAVloHxQJSN7b4cmdlZM RT3vjrJlfSuUxpe8HRVq8hdReCZ5HGeSol3IQUCr7zDLalVAu36WZ7ucXwm47g/CibmYnMNZy/kNg JmBhknuu2u3VEQuCSZ9kvZtaQovwPFk0BxLc6cIczJra8l/aAtrJED3LMlrfWB2wBNrOsfz7oQSBE Gu85jvT2czXOeA==; Received: from acorallo by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1qVZM5-0004vt-CJ; Mon, 14 Aug 2023 11:19:42 -0400 From: Andrea Corallo In-Reply-To: <834jl1bqvl.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 14 Aug 2023 18:11:42 +0300") References: <838ragdzw5.fsf@gnu.org> <83cyzpbyuz.fsf@gnu.org> <835y5hbsc2.fsf@gnu.org> <834jl1bqvl.fsf@gnu.org> Date: Mon, 14 Aug 2023 11:19:41 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: >> From: Andrea Corallo >> Cc: 65250@debbugs.gnu.org >> Date: Mon, 14 Aug 2023 10:51:46 -0400 >> >> Eli Zaretskii 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. Thanks Andrea From unknown Sun Jun 22 04:14:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#65250: 30.0.50; "C-h f" is much slower on the master branch Resent-From: Andrea Corallo Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 14 Aug 2023 15:46:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65250 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 65250@debbugs.gnu.org Received: via spool by 65250-submit@debbugs.gnu.org id=B65250.169202792911954 (code B ref 65250); Mon, 14 Aug 2023 15:46:01 +0000 Received: (at 65250) by debbugs.gnu.org; 14 Aug 2023 15:45:29 +0000 Received: from localhost ([127.0.0.1]:34224 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qVZl2-00036k-Pv for submit@debbugs.gnu.org; Mon, 14 Aug 2023 11:45:29 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:47392) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qVZl0-00036W-DN for 65250@debbugs.gnu.org; Mon, 14 Aug 2023 11:45:27 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qVZku-0006rj-Uo for 65250@debbugs.gnu.org; Mon, 14 Aug 2023 11:45:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To: From; bh=nMHdHCrhvcviyuZ4rDg6kA7Wgn6ZpgW3v6A812xCz2U=; b=oo/QsCpx+VnABH9pxcqt RRxH4wmr2SydElz0Z0UGR6bzZELor3V2trKV0YMHVHA1J0iexPwGFs/omFjue+jdg8GjuUYXmMqoQ CK/pny3CW/Kw6TaUz7xqKbH0VtjwyT62qYVz4nIa5RIIi7qy0WQSzaHnBspc1q3r7q+Jm0gHxNPz1 22+4V3K9PnLG+CiF/GA3sCsV1f8xqWe5yqMYK42nW2/8cOhcgfCuNN/l9G74EuR7+Tt5qzhIV1Qs9 rWMVw+lapDlX+woP8SUPdcVeY0t7aPyKXxhQjtP1MU5jZlUabvlj3Vsykr0XRLMA3k9p/NegG7QCW IZzLQo4BhE5kOw==; Received: from acorallo by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1qVZkr-0001xu-Gv; Mon, 14 Aug 2023 11:45:18 -0400 From: Andrea Corallo In-Reply-To: (Andrea Corallo's message of "Mon, 14 Aug 2023 11:19:41 -0400") References: <838ragdzw5.fsf@gnu.org> <83cyzpbyuz.fsf@gnu.org> <835y5hbsc2.fsf@gnu.org> <834jl1bqvl.fsf@gnu.org> Date: Mon, 14 Aug 2023 11:45:17 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Andrea Corallo writes: > Eli Zaretskii writes: > >>> From: Andrea Corallo >>> Cc: 65250@debbugs.gnu.org >>> Date: Mon, 14 Aug 2023 10:51:46 -0400 >>> >>> Eli Zaretskii 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! From unknown Sun Jun 22 04:14:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#65250: 30.0.50; "C-h f" is much slower on the master branch Resent-From: Andrea Corallo Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 16 Aug 2023 08:38:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65250 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 65250@debbugs.gnu.org Received: via spool by 65250-submit@debbugs.gnu.org id=B65250.169217507618820 (code B ref 65250); Wed, 16 Aug 2023 08:38:01 +0000 Received: (at 65250) by debbugs.gnu.org; 16 Aug 2023 08:37:56 +0000 Received: from localhost ([127.0.0.1]:38804 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qWC2N-0004tU-NY for submit@debbugs.gnu.org; Wed, 16 Aug 2023 04:37:56 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:45834) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qWC2L-0004tH-Sa for 65250@debbugs.gnu.org; Wed, 16 Aug 2023 04:37:55 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qWC2G-0006z9-FS for 65250@debbugs.gnu.org; Wed, 16 Aug 2023 04:37:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To: From; bh=NynIiKf0H6v1iCc2iNbBVvx0U0D/CIjhzykMPxdP9e4=; b=O9pdM2SIciFBpVBqQ/BY /yZUxM/9F2IeOqtRaCegAiYqLjlLOsT4bUT5KN3WtMQs2e0LSt7ipY2upcQUwIgmsUrZq3MBP3Q9m HfG3QwlwPNROKekQWlc8sohs6foYSsg5Db3bzqq3CabbSHnwzfEDhgWErOMpgIwtkjOgGrnwU9sue kcdEG2ZV1FfPu6Qut4ukV1sQjV20WKQWCWH3X3vt2upGqX8tYatpxoqkOzus1vGHC4j+pbNCL64cm cDpvr8+gW4yNLKz7ME1cRXJglnaSMigwd4D+KTeebqG8Rmr7OcdmCWJDyaj0nfVy8c8YMWRxxvFIb MFqasVxqPumEtA==; Received: from acorallo by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1qWC24-0007NN-RL; Wed, 16 Aug 2023 04:37:48 -0400 From: Andrea Corallo In-Reply-To: (Andrea Corallo's message of "Mon, 14 Aug 2023 11:45:17 -0400") References: <838ragdzw5.fsf@gnu.org> <83cyzpbyuz.fsf@gnu.org> <835y5hbsc2.fsf@gnu.org> <834jl1bqvl.fsf@gnu.org> Date: Wed, 16 Aug 2023 04:37:36 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Andrea Corallo writes: > Andrea Corallo writes: > >> Eli Zaretskii writes: >> >>>> From: Andrea Corallo >>>> Cc: 65250@debbugs.gnu.org >>>> Date: Mon, 14 Aug 2023 10:51:46 -0400 >>>> >>>> Eli Zaretskii 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 From unknown Sun Jun 22 04:14:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#65250: 30.0.50; "C-h f" is much slower on the master branch Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 16 Aug 2023 13:13:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65250 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Andrea Corallo Cc: 65250@debbugs.gnu.org Received: via spool by 65250-submit@debbugs.gnu.org id=B65250.16921915486244 (code B ref 65250); Wed, 16 Aug 2023 13:13:02 +0000 Received: (at 65250) by debbugs.gnu.org; 16 Aug 2023 13:12:28 +0000 Received: from localhost ([127.0.0.1]:39547 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qWGK3-0001ce-Ti for submit@debbugs.gnu.org; Wed, 16 Aug 2023 09:12:28 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:58878) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qWGK2-0001cR-Te for 65250@debbugs.gnu.org; Wed, 16 Aug 2023 09:12:27 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qWGJx-0002hu-LL for 65250@debbugs.gnu.org; Wed, 16 Aug 2023 09:12:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=9yo/qbNh89yUSaYr35kqDtxPXY60Hm0fdsfclW11UMA=; b=HjyxBhsRGw5i r9/EC9Fy3fJ3xe4MdojZU0G4KWZvu7TFFgtT4uAfYq40bK5+I9keS4GBN3RH/gYSkoQK8/70D6aec o7Dl5yBDzUpIprlBFjguCmWWMCCaySx+2X/GRJ+7jewsI0TkuLaqNOF8uyYrCeqGGM5Q0hebiACsa pI3AND8JSEBfD3MdtECAnL4hcywy1f8sDGWE0V+OGDsvDrlQQfFweqeq67G6k+KJWJW58ULZxH/eD Q/1tDo4HCRpFF7xJctLH4QYHfdy7JJVYfb5EI7V4Kv35Ne5uSt/hQnZzhMhQGiC+UaLuilHJMn0qa Qf2He6mEP2pSPU2JMCfOhA==; Date: Wed, 16 Aug 2023 16:12:25 +0300 Message-Id: <83edk3872e.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Andrea Corallo on Wed, 16 Aug 2023 04:37:36 -0400) References: <838ragdzw5.fsf@gnu.org> <83cyzpbyuz.fsf@gnu.org> <835y5hbsc2.fsf@gnu.org> <834jl1bqvl.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Andrea Corallo > Cc: 65250@debbugs.gnu.org > Date: Wed, 16 Aug 2023 04:37:36 -0400 > > Okay I pushed 2eaf1e3efca to always byte-compile native comp related > files also on non native builds. Thanks. > 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. Done. > Before installing it, even in non native builds, C-h f was showing the > type for functions listed in `comp-known-type-specifiers'. How can I see this capability? From unknown Sun Jun 22 04:14:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#65250: 30.0.50; "C-h f" is much slower on the master branch Resent-From: Andrea Corallo Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 16 Aug 2023 13:57:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65250 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 65250@debbugs.gnu.org Received: via spool by 65250-submit@debbugs.gnu.org id=B65250.169219419013452 (code B ref 65250); Wed, 16 Aug 2023 13:57:02 +0000 Received: (at 65250) by debbugs.gnu.org; 16 Aug 2023 13:56:30 +0000 Received: from localhost ([127.0.0.1]:41725 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qWH0f-0003Uu-T0 for submit@debbugs.gnu.org; Wed, 16 Aug 2023 09:56:30 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:36208) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qWH0d-0003Um-QK for 65250@debbugs.gnu.org; Wed, 16 Aug 2023 09:56:28 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qWH0X-0005Qy-5G for 65250@debbugs.gnu.org; Wed, 16 Aug 2023 09:56:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To: From; bh=bp+ea7/Qpa53nAUEwdWrHqGfgJPOn9wEwR2mvkRy7eg=; b=OROVqXOI2bfIDahKVY19 QpMtPcNfHnpuWvfjWvaAiFAdNdczgaK+ZTxitWhetX12uQdTAvpzmI1fou41c1GezhwsiTS60GCxS G8yJfa1xlrYgRWREUvY8U8PbKI0v2YpUYRx/E6gWw96y7UMYBaNDbAJNU7quzmhxphrvR+7icb7S7 1dQLR6pd/ZAv0PMYUkw2e/m5S6a5Xn+kO4VJVMG5r7A32ijQl38IHgWueMIGrN5F3Zr/nsgp4C62M HkmfWSENBqB7cJhvgM8Aw5vcHWD3KJfhdMZxHPWgkYRbPXnSOfO+yxN+8mK5Id9U0HuygvP8u9yro 1GYiaLwZfpoNEQ==; Received: from acorallo by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1qWGzY-0006oL-0I; Wed, 16 Aug 2023 09:55:21 -0400 From: Andrea Corallo In-Reply-To: <83edk3872e.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 16 Aug 2023 16:12:25 +0300") References: <838ragdzw5.fsf@gnu.org> <83cyzpbyuz.fsf@gnu.org> <835y5hbsc2.fsf@gnu.org> <834jl1bqvl.fsf@gnu.org> <83edk3872e.fsf@gnu.org> Date: Wed, 16 Aug 2023 09:55:19 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: >> From: Andrea Corallo >> Cc: 65250@debbugs.gnu.org >> Date: Wed, 16 Aug 2023 04:37:36 -0400 >> >> Okay I pushed 2eaf1e3efca to always byte-compile native comp related >> files also on non native builds. > > Thanks. > >> 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. > > Done. > >> Before installing it, even in non native builds, C-h f was showing the >> type for functions listed in `comp-known-type-specifiers'. > > How can I see this capability? Should be sufficient say 'C-h f +'. (+ or any function in comp-known-type-specifiers). Best Regards Andrea From unknown Sun Jun 22 04:14:29 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.505 (Entity 5.505) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: Eli Zaretskii Subject: bug#65250: closed (Re: bug#65250: 30.0.50; "C-h f" is much slower on the master branch) Message-ID: References: <83350j82gc.fsf@gnu.org> <838ragdzw5.fsf@gnu.org> X-Gnu-PR-Message: they-closed 65250 X-Gnu-PR-Package: emacs Reply-To: 65250@debbugs.gnu.org Date: Wed, 16 Aug 2023 14:53:02 +0000 Content-Type: multipart/mixed; boundary="----------=_1692197582-29281-1" This is a multi-part message in MIME format... ------------=_1692197582-29281-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #65250: 30.0.50; "C-h f" is much slower on the master branch which was filed against the emacs package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 65250@debbugs.gnu.org. --=20 65250: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D65250 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1692197582-29281-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 65250-done) by debbugs.gnu.org; 16 Aug 2023 14:52:19 +0000 Received: from localhost ([127.0.0.1]:41831 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qWHsh-0007bI-BV for submit@debbugs.gnu.org; Wed, 16 Aug 2023 10:52:19 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:53238) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qWHsf-0007b4-DU for 65250-done@debbugs.gnu.org; Wed, 16 Aug 2023 10:52:17 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qWHsa-00017z-6u for 65250-done@debbugs.gnu.org; Wed, 16 Aug 2023 10:52:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=YV1Ldy8gwMi0i91xvhbwHZlZFiJ0m7TqCHx6A7pCoSY=; b=JkVdOyDdxzS9 fcfaKZTNrupEqNQDRZ+JV7oRAgcfTGu5ss0D+isFEdo8yWbmaDsXDiGzrFyVc5rMfKB4iAwpuuq2M PGYdOvRbj5iASm3wZZh114j/Iet3P/NofyBv4lJPsbgP6opvXxxmRFgFpwMzVra9yDTzuD42YNrhu T2TT0EBolUn97N8V0u0WnGQqYr7KjrcVfO0IKtwH+k1iR7PbkUaugxhURN6rYHj7zQr+LU7/tQkBZ 3yt3aUA9My0mM2YMvjAp7C42hpjVThlnEeW3rJCkDt45K3ZzJ8rrYPJtZd6UQ3ORYc2PoXq3XT7Hy lvkUpBm90KSgzeD8BYzo0w==; Date: Wed, 16 Aug 2023 17:52:03 +0300 Message-Id: <83350j82gc.fsf@gnu.org> From: Eli Zaretskii To: Andrea Corallo In-Reply-To: (message from Andrea Corallo on Wed, 16 Aug 2023 09:55:19 -0400) Subject: Re: bug#65250: 30.0.50; "C-h f" is much slower on the master branch References: <838ragdzw5.fsf@gnu.org> <83cyzpbyuz.fsf@gnu.org> <835y5hbsc2.fsf@gnu.org> <834jl1bqvl.fsf@gnu.org> <83edk3872e.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 65250-done Cc: 65250-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Andrea Corallo > Cc: 65250@debbugs.gnu.org > Date: Wed, 16 Aug 2023 09:55:19 -0400 > > Eli Zaretskii writes: > > >> Before installing it, even in non native builds, C-h f was showing the > >> type for functions listed in `comp-known-type-specifiers'. > > > > How can I see this capability? > > Should be sufficient say 'C-h f +'. OK, works here in a build without native compilation. So I think we can now close this bug. ------------=_1692197582-29281-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 12 Aug 2023 15:49:09 +0000 Received: from localhost ([127.0.0.1]:56671 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qUqrU-0000EU-MW for submit@debbugs.gnu.org; Sat, 12 Aug 2023 11:49:09 -0400 Received: from lists.gnu.org ([2001:470:142::17]:45812) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qUqrR-0000Dx-0J for submit@debbugs.gnu.org; Sat, 12 Aug 2023 11:49:06 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qUqrL-0000vS-9O for bug-gnu-emacs@gnu.org; Sat, 12 Aug 2023 11:48:59 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qUqrL-0004v2-14 for bug-gnu-emacs@gnu.org; Sat, 12 Aug 2023 11:48:59 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=Subject:To:From:Date:mime-version:in-reply-to: references; bh=25m7hNC6gWsPFXg9RoPKoGjItsEdM33lstymcMLBWDA=; b=MNX4mrRZenGlvU bO7/Z5VPyJu+G5f0S9T4iwbaXIPLvfQ5+X60e52ffJdfb3qkHpBaj9WGXdFX5FTqvnixVnC2HeGvr x+7WPuIhG5Nxt1YmhdTJDY0xjCNjU1lRf6BL7fMsTQ5tLGNx1l/DoSQcXJGQuSCiRF7X53ndO0aX9 Hh/13w6MO2ODhFSEZi9UWRrnCKjD+z4itSPueVNTw2/QhyhcZ480hLXn+5C4mhjz8/qQ8QkyWsuYm P54i3S81WV/lkFTUeIJx75opN8pe80QpCIYuuf2D+tyEfcpdxJ+ApMDgNxzycF4rk6KnBxpy/iRgc uCeMH37KFRDto0SHFppg==; Date: Sat, 12 Aug 2023 18:49:30 +0300 Message-Id: <838ragdzw5.fsf@gnu.org> From: Eli Zaretskii To: bug-gnu-emacs@gnu.org Subject: 30.0.50; "C-h f" is much slower on the master branch X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) To reproduce: emacs -Q C-h f dictionary-search RET (almost any other function will do, I think). This takes a whopping 6.6 sec of CPU on master, vs 2.4 sec on the emacs-29 branch. These are both unoptimized builds, but even so, 6.6 seconds of CPU time for looking up a doc string of a function is too much, I think. The patch below fixes the problem in a build without native-compilation, but won't help in a build with native-compilation. I wonder why comp-function-type-spec is so expensive? In GNU Emacs 30.0.50 (build 417, i686-pc-mingw32) of 2023-08-12 built on HOME-C4E4A596F7 Repository revision: d3dae88e6cc8118c875957ba0347be9599014b34 Repository branch: master Windowing system distributor 'Microsoft Corp.', version 5.1.2600 System Description: Microsoft Windows XP Service Pack 3 (v5.1.0.2600) Configured using: 'configure -C --prefix=/d/usr --with-wide-int --enable-checking=yes,glyphs 'CFLAGS=-O0 -gdwarf-4 -g3'' Configured features: ACL GIF GMP GNUTLS HARFBUZZ JPEG JSON LCMS2 LIBXML2 MODULES NOTIFY W32NOTIFY PDUMPER PNG RSVG SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XPM ZLIB Important settings: value of $LANG: ENU locale-coding-system: cp1255 Major mode: Lisp Interaction Minor modes in effect: tooltip-mode: t global-eldoc-mode: t eldoc-mode: t show-paren-mode: t electric-indent-mode: t mouse-wheel-mode: t tool-bar-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t line-number-mode: t indent-tabs-mode: t transient-mark-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t Load-path shadows: None found. Features: (shadow sort mail-extr emacsbug message mailcap yank-media puny dired dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068 epg-config gnus-util text-property-search time-date subr-x mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils rmc iso-transl tooltip cconv eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel dos-w32 ls-lisp disp-table term/w32-win w32-win w32-vars term/common-win touch-screen tool-bar dnd fontset image regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors frame minibuffer nadvice seq simple cl-generic indonesian philippine cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese composite emoji-zwj charscript charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp files window text-properties overlay sha1 md5 base64 format env code-pages mule custom widget keymap hashtable-print-readable backquote threads w32notify w32 lcms2 multi-tty move-toolbar make-network-process emacs) Memory information: ((conses 16 42844 17019) (symbols 48 6336 0) (strings 16 16702 3269) (string-bytes 1 401689) (vectors 16 9351) (vector-slots 8 147820 16098) (floats 8 23 25) (intervals 40 276 95) (buffers 896 10)) Here's the patch I promised: diff --git a/lisp/help-fns.el b/lisp/help-fns.el index fc8f431..bedc5a9 100644 --- a/lisp/help-fns.el +++ b/lisp/help-fns.el @@ -715,7 +715,8 @@ help-fns--signature (unless (and (symbolp function) (get function 'reader-construct)) (insert high-usage "\n") - (when-let* ((res (comp-function-type-spec function)) + (when-let* ((res (and (native-comp-available-p) + (comp-function-type-spec function))) (type-spec (car res)) (kind (cdr res))) (insert (format ------------=_1692197582-29281-1--