From debbugs-submit-bounces@debbugs.gnu.org Sat Aug 12 11:49:09 2023 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 From debbugs-submit-bounces@debbugs.gnu.org Sat Aug 12 12:57:38 2023 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 To: Eli Zaretskii Subject: Re: bug#65250: 30.0.50; "C-h f" is much slower on the master branch 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-Debbugs-Envelope-To: 65250 Cc: 65250@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 (---) 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 debbugs-submit-bounces@debbugs.gnu.org Sat Aug 12 13:23:13 2023 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 To: Andrea Corallo In-Reply-To: (message from Andrea Corallo on Sat, 12 Aug 2023 12:57:27 -0400) Subject: Re: bug#65250: 30.0.50; "C-h f" is much slower on the master branch References: <838ragdzw5.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 65250 Cc: 65250@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: 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 debbugs-submit-bounces@debbugs.gnu.org Mon Aug 14 04:59:45 2023 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 To: Eli Zaretskii Subject: Re: bug#65250: 30.0.50; "C-h f" is much slower on the master branch 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-Debbugs-Envelope-To: 65250 Cc: 65250@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 (---) 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 debbugs-submit-bounces@debbugs.gnu.org Mon Aug 14 08:19:22 2023 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 To: Andrea Corallo In-Reply-To: (message from Andrea Corallo on Mon, 14 Aug 2023 04:59:18 -0400) Subject: Re: bug#65250: 30.0.50; "C-h f" is much slower on the master branch References: <838ragdzw5.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 65250 Cc: 65250@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: 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 debbugs-submit-bounces@debbugs.gnu.org Mon Aug 14 10:40:44 2023 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 To: acorallo@gnu.org In-Reply-To: <83cyzpbyuz.fsf@gnu.org> (message from Eli Zaretskii on Mon, 14 Aug 2023 15:19:16 +0300) 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> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 65250 Cc: 65250@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 (---) > 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 debbugs-submit-bounces@debbugs.gnu.org Mon Aug 14 10:51:55 2023 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 To: Eli Zaretskii Subject: Re: bug#65250: 30.0.50; "C-h f" is much slower on the master branch 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-Debbugs-Envelope-To: 65250 Cc: 65250@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 (---) 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 debbugs-submit-bounces@debbugs.gnu.org Mon Aug 14 11:11:49 2023 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 To: Andrea Corallo In-Reply-To: (message from Andrea Corallo on Mon, 14 Aug 2023 10:51:46 -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> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 65250 Cc: 65250@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: 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 debbugs-submit-bounces@debbugs.gnu.org Mon Aug 14 11:19:50 2023 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 To: Eli Zaretskii Subject: Re: bug#65250: 30.0.50; "C-h f" is much slower on the master branch 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-Debbugs-Envelope-To: 65250 Cc: 65250@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 (---) 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 debbugs-submit-bounces@debbugs.gnu.org Mon Aug 14 11:45:29 2023 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 To: Eli Zaretskii Subject: Re: bug#65250: 30.0.50; "C-h f" is much slower on the master branch 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-Debbugs-Envelope-To: 65250 Cc: 65250@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 (---) 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 debbugs-submit-bounces@debbugs.gnu.org Wed Aug 16 04:37:56 2023 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 To: Eli Zaretskii Subject: Re: bug#65250: 30.0.50; "C-h f" is much slower on the master branch 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-Debbugs-Envelope-To: 65250 Cc: 65250@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 (---) 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 debbugs-submit-bounces@debbugs.gnu.org Wed Aug 16 09:12:28 2023 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 To: Andrea Corallo In-Reply-To: (message from Andrea Corallo on Wed, 16 Aug 2023 04:37:36 -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> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 65250 Cc: 65250@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 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 debbugs-submit-bounces@debbugs.gnu.org Wed Aug 16 09:56:30 2023 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 To: Eli Zaretskii Subject: Re: bug#65250: 30.0.50; "C-h f" is much slower on the master branch 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-Debbugs-Envelope-To: 65250 Cc: 65250@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 (---) 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 debbugs-submit-bounces@debbugs.gnu.org Wed Aug 16 10:52:19 2023 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. From unknown Fri Aug 15 20:04:50 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Thu, 14 Sep 2023 11:24:11 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator