From unknown Sun Jun 22 11:30:58 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#52298 <52298@debbugs.gnu.org> To: bug#52298 <52298@debbugs.gnu.org> Subject: Status: 29.0.50; Frequent redisplay cycles induced by c-type-finder-timer-func timer in CC Mode Reply-To: bug#52298 <52298@debbugs.gnu.org> Date: Sun, 22 Jun 2025 18:30:58 +0000 retitle 52298 29.0.50; Frequent redisplay cycles induced by c-type-finder-t= imer-func timer in CC Mode reassign 52298 emacs submitter 52298 Eli Zaretskii severity 52298 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Sun Dec 05 02:46:39 2021 Received: (at submit) by debbugs.gnu.org; 5 Dec 2021 07:46:39 +0000 Received: from localhost ([127.0.0.1]:56219 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mtmEI-0000OU-MW for submit@debbugs.gnu.org; Sun, 05 Dec 2021 02:46:39 -0500 Received: from lists.gnu.org ([209.51.188.17]:53148) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mtmEG-0000ON-Ld for submit@debbugs.gnu.org; Sun, 05 Dec 2021 02:46:37 -0500 Received: from eggs.gnu.org ([209.51.188.92]:55032) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mtmEG-0002zD-Dg for bug-gnu-emacs@gnu.org; Sun, 05 Dec 2021 02:46:36 -0500 Received: from [2001:470:142:3::e] (port=32982 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mtmEF-0005YS-G6; Sun, 05 Dec 2021 02:46:35 -0500 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=HrzTPDe2pkP/QuE7P1IyhGj4jzRMb/RaOPtIQEFXN4E=; b=jZwVfJWTc3h0WS JSXsEHxMEve4hczc4iAXVoAyzssRs+uTdtt69HWgqMgqVMc+TPRsHYDVYnLdD84OiYaE8kmvDzi3J Ozh2EVD1kKVxN+eChokj5EwBIyAKFrJhX9+zJU4Vqj8SFAsl+LJgfm4c2xci90Ehx7aDr4ZBcDAin fCX/iKYnvT3+VLfc9aHQ2QGm8y3vS+JoEq8ZwpM7PkZnRKT11J/rKQ1yK1ffz1JLI7j1wNX9od2n4 riIlDQxXgb0F12pwN2w4E8o1dh/e60SvIDQ3FMTeb/ah1BGvsVgc0l0iL+y8VlqPgoMeiCAyUvWff rJ7jYPxZZd4RrlyuTDoQ==; Received: from [87.69.77.57] (port=4925 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mtmEF-0004Xg-9G; Sun, 05 Dec 2021 02:46:35 -0500 Date: Sun, 05 Dec 2021 09:46:29 +0200 Message-Id: <83sfv74hpm.fsf@gnu.org> From: Eli Zaretskii To: bug-gnu-emacs@gnu.org Subject: 29.0.50; Frequent redisplay cycles induced by c-type-finder-timer-func timer in CC Mode X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: submit Cc: Alan Mackenzie 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 (---) It used to be the case that starting "emacs -Q" and disabling blink-cursor-mode and global-eldoc-mode was enough to get me Emacs that doesn't perform redisplay unless required. To see this, do the following with any Emacs up to and including Emacs 28: emacs -Q M-x blink-cursor-mode RET M-x global-eldoc-mode RET M-x trace-redisplay RET (The last command is only available if you configured with "--enable-checking=yes,glyphs".) This would produce a few lines of output on stderr, and then stop until you do something in Emacs, like move the cursor with an arrow key. This is no longer the case in Emacs 29. There, if you visit a C file, you will see a flurry of stderr messages about constant redisplay cycles being forced. It seems like the culprit is the function 'c-type-finder-timer-func', which is run from a timer at 10 Hz (!), and which for some reason forces Emacs to perform a redisplay cycle with that frequency. The trace itself, viz.: redisplay_internal 0 071a03c8 (xdisp.c): try_window_id 2 redisplay_preserve_echo_area (8) means that the processing induced by that timer function is far from being trivial, which means something that this function does causes Emacs to think some real change might have happened in the buffer. Not even "emacs -Q -D" is enough to get rid of this 'c-type-finder-timer-func' timer in CC Mode buffers. Is it possible to prevent this frequent timer from firing when no changes have been done to the buffer? And in any case, please try to include some logic in that function to avoid whatever it does now to force such frequent non-trivial redisplay cycles. If nothing else, laptop users will hate us if we release Emacs with this behavior. In GNU Emacs 29.0.50 (build 297, i686-pc-mingw32) of 2021-12-04 built on HOME-C4E4A596F7 Repository revision: f247fa5d5ce7cb34f23c979c17b14c5713eb5490 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 THREADS TIFF TOOLKIT_SCROLL_BARS WEBP XPM ZLIB Important settings: value of $LANG: ENU locale-coding-system: cp1255 Major mode: Lisp Interaction Minor modes in effect: tooltip-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 auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t line-number-mode: t indent-tabs-mode: t transient-mark-mode: t Load-path shadows: None found. Features: (shadow sort mail-extr emacsbug message mailcap yank-media rmc puny dired dired-loaddefs rfc822 mml mml-sec epa derived epg rfc6068 epg-config gnus-util rmail rmail-loaddefs auth-source cl-seq eieio eieio-core cl-macs eieio-loaddefs password-cache json map text-property-search time-date seq gv subr-x byte-opt bytecomp byte-compile cconv 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 cus-start cus-load iso-transl tooltip 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 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 cl-generic 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 simple abbrev obarray cl-preloaded nadvice button 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 make-network-process emacs) Memory information: ((conses 16 65940 11920) (symbols 48 8784 1) (strings 16 23857 3044) (string-bytes 1 667119) (vectors 16 14295) (vector-slots 8 183967 12730) (floats 8 25 52) (intervals 40 273 68) (buffers 888 10)) From debbugs-submit-bounces@debbugs.gnu.org Mon Dec 06 15:53:25 2021 Received: (at submit) by debbugs.gnu.org; 6 Dec 2021 20:53:25 +0000 Received: from localhost ([127.0.0.1]:35528 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1muKzE-0000MI-OR for submit@debbugs.gnu.org; Mon, 06 Dec 2021 15:53:25 -0500 Received: from lists.gnu.org ([209.51.188.17]:53318) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1muKzB-0000M9-SY for submit@debbugs.gnu.org; Mon, 06 Dec 2021 15:53:23 -0500 Received: from eggs.gnu.org ([209.51.188.92]:42484) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1muKzB-0006xW-EQ for bug-gnu-emacs@gnu.org; Mon, 06 Dec 2021 15:53:21 -0500 Received: from colin.muc.de ([193.149.48.1]:18763 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1muKz8-0003Qp-Sy for bug-gnu-emacs@gnu.org; Mon, 06 Dec 2021 15:53:21 -0500 Received: (qmail 13305 invoked by uid 3782); 6 Dec 2021 20:53:16 -0000 Received: from acm.muc.de (p4fe15d73.dip0.t-ipconnect.de [79.225.93.115]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 06 Dec 2021 21:53:16 +0100 Received: (qmail 402 invoked by uid 1000); 6 Dec 2021 20:53:15 -0000 Date: Mon, 6 Dec 2021 20:53:15 +0000 To: Eli Zaretskii Subject: Re: 29.0.50; Frequent redisplay cycles induced by c-type-finder-timer-func timer in CC Mode Message-ID: References: <83sfv74hpm.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83sfv74hpm.fsf@gnu.org> X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de Received-SPF: pass client-ip=193.149.48.1; envelope-from=acm@muc.de; helo=mail.muc.de X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=unavailable autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.6 (-) X-Debbugs-Envelope-To: submit Cc: bug-gnu-emacs@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: -2.6 (--) Hello, Eli. On Sun, Dec 05, 2021 at 09:46:29 +0200, Eli Zaretskii wrote: > It used to be the case that starting "emacs -Q" and disabling > blink-cursor-mode and global-eldoc-mode was enough to get me Emacs > that doesn't perform redisplay unless required. To see this, do the > following with any Emacs up to and including Emacs 28: > emacs -Q > M-x blink-cursor-mode RET > M-x global-eldoc-mode RET > M-x trace-redisplay RET > (The last command is only available if you configured with > "--enable-checking=yes,glyphs".) This would produce a few lines of > output on stderr, and then stop until you do something in Emacs, like > move the cursor with an arrow key. > This is no longer the case in Emacs 29. There, if you visit a C file, > you will see a flurry of stderr messages about constant redisplay > cycles being forced. It seems like the culprit is the function > 'c-type-finder-timer-func', which is run from a timer at 10 Hz (!), That is customisable with c-type-finder-repeat-time. The idea is to have this as often as possible so that the backgroud scanning is complete as soon as possible. (See my next paragraph.) > and which for some reason forces Emacs to perform a redisplay cycle > with that frequency. The trace itself, viz.: > redisplay_internal 0 > 071a03c8 (xdisp.c): try_window_id 2 > redisplay_preserve_echo_area (8) > means that the processing induced by that timer function is far from > being trivial, which means something that this function does causes > Emacs to think some real change might have happened in the buffer. The idea is that this processing only happens a short while after loading a C file, the time being taken up by checking for the fontification of "found types", that is identifiers identified as types in the rest of the buffer somewhere. > Not even "emacs -Q -D" is enough to get rid of this > 'c-type-finder-timer-func' timer in CC Mode buffers. If this processing continues beyond the time to scan all CC Mode buffers, then there is a bug. A megabyte long file (xdisp.c) scans in aroung 18 seconds on my machine. > Is it possible to prevent this frequent timer from firing when no > changes have been done to the buffer? And in any case, please try to > include some logic in that function to avoid whatever it does now to > force such frequent non-trivial redisplay cycles. If nothing else, > laptop users will hate us if we release Emacs with this behavior. It can be disabled by setting (or customising) c-type-finder-time-slot to nil. As I say, the activity should cease after a few seconds, or a few minutes with a well filled desktop. There have been a couple of bugs in this area recently, one fixed (stupidly) on the release branch (where there wasn't a problem). The other one was fixed in master. By recently, I mean last Wednesday and Saturday 2021-11-13. But even given the above, I've a sneaking suspicion there's still a bug here, which I'll have a look for (but not tonight). > In GNU Emacs 29.0.50 (build 297, i686-pc-mingw32) > of 2021-12-04 built on HOME-C4E4A596F7 > Repository revision: f247fa5d5ce7cb34f23c979c17b14c5713eb5490 > 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'' [ .... ] -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 07 07:58:16 2021 Received: (at 52298) by debbugs.gnu.org; 7 Dec 2021 12:58:16 +0000 Received: from localhost ([127.0.0.1]:36573 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mua2y-0004R4-01 for submit@debbugs.gnu.org; Tue, 07 Dec 2021 07:58:16 -0500 Received: from eggs.gnu.org ([209.51.188.92]:44652) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mua2w-0004Qr-LE for 52298@debbugs.gnu.org; Tue, 07 Dec 2021 07:58:15 -0500 Received: from [2001:470:142:3::e] (port=38316 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mua2q-0004Hn-Vv; Tue, 07 Dec 2021 07:58:08 -0500 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=7EEj0FADw3J8ea1J+iLiuIChqypW5YnXYqAAh5k7NlU=; b=rVASVVB1hkPC Ehy8kzrllcLjgNQGJpPvTA7XHhy+7hGwV5bc7RQxtp4CiDrjTv1Hl+gQsyaGoLIpz/P/jrannUSxs /AUc7U7aTwV+696vTyMzKPkEdBt+MRiDAMAQe7/5sfil+H1Tp51FPG9mTRcdXTTo/5SDiefL7vzaM haVcCd9BeoWfTHPvIff800HEL8Mml2loBP+iQp6gYTZcFb2JEMHD+im0hZjeECLnE3lBUyYxPldLF UJylyFPhYmkZv3P7LdkLtK2Ff6GwFsIWHygBPGGLSL5+GChFkHGaBjAAf7cPyPhRwNDo7A5eAz1Yz bCCq9OY2A3YC9092kQr5XA==; Received: from [87.69.77.57] (port=3223 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mua2q-0004ZL-JD; Tue, 07 Dec 2021 07:58:08 -0500 Date: Tue, 07 Dec 2021 14:58:08 +0200 Message-Id: <83pmq8zi5b.fsf@gnu.org> From: Eli Zaretskii To: Alan Mackenzie In-Reply-To: (message from Alan Mackenzie on Mon, 6 Dec 2021 20:53:15 +0000) Subject: Re: bug#52298: 29.0.50; Frequent redisplay cycles induced by c-type-finder-timer-func timer in CC Mode References: <83sfv74hpm.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 52298 Cc: 52298@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 (---) > Date: Mon, 6 Dec 2021 20:53:15 +0000 > Cc: bug-gnu-emacs@gnu.org > From: Alan Mackenzie > > > This is no longer the case in Emacs 29. There, if you visit a C file, > > you will see a flurry of stderr messages about constant redisplay > > cycles being forced. It seems like the culprit is the function > > 'c-type-finder-timer-func', which is run from a timer at 10 Hz (!), > > That is customisable with c-type-finder-repeat-time. The idea is to > have this as often as possible so that the backgroud scanning is > complete as soon as possible. (See my next paragraph.) Yes, but why would I need to do one more chore to get me a "silent" redisplay? And why does this timer cause such a serious work to the display engine? > If this processing continues beyond the time to scan all CC Mode > buffers, then there is a bug. A megabyte long file (xdisp.c) scans in > aroung 18 seconds on my machine. 18 seconds is almost an eternity for my frequent use cases of firing up Emacs to debug some display problem. And it's much more than 18 sec here: I measured 4 minutes and 21 sec, with 1:54 CPU time. My build is unoptimized, but still, a factor of 13 wrt your timing is too much to be explained by that alone. > It can be disabled by setting (or customising) c-type-finder-time-slot > to nil. As I say, the activity should cease after a few seconds, or a > few minutes with a well filled desktop. Once again, it takes much more here. And my main question was left unanswered: what does this timer function do to cause such thorough redisplay cycles, when I know that nothing was changed in the buffer? can you please describe what this function does that could have such an effect? From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 07 14:58:55 2021 Received: (at 52298) by debbugs.gnu.org; 7 Dec 2021 19:58:55 +0000 Received: from localhost ([127.0.0.1]:38693 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mugc3-0001OC-7o for submit@debbugs.gnu.org; Tue, 07 Dec 2021 14:58:55 -0500 Received: from colin.muc.de ([193.149.48.1]:55603 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1mugby-0001Ns-0D for 52298@debbugs.gnu.org; Tue, 07 Dec 2021 14:58:54 -0500 Received: (qmail 49274 invoked by uid 3782); 7 Dec 2021 19:58:40 -0000 Received: from acm.muc.de (p4fe15c4e.dip0.t-ipconnect.de [79.225.92.78]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Tue, 07 Dec 2021 20:58:40 +0100 Received: (qmail 8252 invoked by uid 1000); 7 Dec 2021 19:58:39 -0000 Date: Tue, 7 Dec 2021 19:58:39 +0000 To: Eli Zaretskii Subject: Re: bug#52298: 29.0.50; Frequent redisplay cycles induced by c-type-finder-timer-func timer in CC Mode Message-ID: References: <83sfv74hpm.fsf@gnu.org> <83pmq8zi5b.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83pmq8zi5b.fsf@gnu.org> X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 52298 Cc: acm@muc.de, 52298@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: -1.0 (-) Hello, Eli. On Tue, Dec 07, 2021 at 14:58:08 +0200, Eli Zaretskii wrote: > > Date: Mon, 6 Dec 2021 20:53:15 +0000 > > Cc: bug-gnu-emacs@gnu.org > > From: Alan Mackenzie > > > This is no longer the case in Emacs 29. There, if you visit a C file, > > > you will see a flurry of stderr messages about constant redisplay > > > cycles being forced. It seems like the culprit is the function > > > 'c-type-finder-timer-func', which is run from a timer at 10 Hz (!), > > That is customisable with c-type-finder-repeat-time. The idea is to > > have this as often as possible so that the backgroud scanning is > > complete as soon as possible. (See my next paragraph.) > Yes, but why would I need to do one more chore to get me a "silent" > redisplay? And why does this timer cause such a serious work to the > display engine? I think there's still a bug in the mechanism. This mechanism was the outcome of a long thread in the list a few months ago, complaining about the perceived randomness of CC Mode's font locking. It scans all CC Mode buffers at startup, and each buffer which gets visited, to detect "found types". For each occurrence anywhere in the buffer of a newly "found type", the fontified text property gets set to nil. Further, if this occurrence is in a currently displayed window, a redisplay gets triggered. In a (hopefully fixed) bug, there occurred constant redisplay, because the newly found types weren't getting properly added to c-found-type-list. The same thing might still be happening in a different way. > > If this processing continues beyond the time to scan all CC Mode > > buffers, then there is a bug. A megabyte long file (xdisp.c) scans in > > aroung 18 seconds on my machine. > 18 seconds is almost an eternity for my frequent use cases of firing > up Emacs to debug some display problem. And it's much more than 18 > sec here: I measured 4 minutes and 21 sec, with 1:54 CPU time. My > build is unoptimized, but still, a factor of 13 wrt your timing is too > much to be explained by that alone. Is that with xdisp.c the only CC Mode buffer? When my desktop had around 700 buffers, many of them CC Mode, the total background processing was of the order of 10 minutes (optimised build). That 4 minutes 21 seconds - does the thrashing of the redisplay stop after this amount of uptime? As a matter of interest, is Emacs responsive to key strokes when this is happening? > > It can be disabled by setting (or customising) c-type-finder-time-slot > > to nil. As I say, the activity should cease after a few seconds, or a > > few minutes with a well filled desktop. > Once again, it takes much more here. And my main question was left > unanswered: what does this timer function do to cause such thorough > redisplay cycles, when I know that nothing was changed in the buffer? > can you please describe what this function does that could have such > an effect? What changes in the buffer is the detection of "foo", "bar", ... as found types. These get marked throughout the buffer with the fontified text property set to nil, and if an occurrence is in a displayed window, that triggers an immediate redisplay to refontify that visible occurrence of the found type. I think this repeated redisplay is happening too often. -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 07 15:16:47 2021 Received: (at 52298) by debbugs.gnu.org; 7 Dec 2021 20:16:47 +0000 Received: from localhost ([127.0.0.1]:38737 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mugtK-0001sE-NB for submit@debbugs.gnu.org; Tue, 07 Dec 2021 15:16:46 -0500 Received: from eggs.gnu.org ([209.51.188.92]:59612) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mugtH-0001rt-PO for 52298@debbugs.gnu.org; Tue, 07 Dec 2021 15:16:44 -0500 Received: from [2001:470:142:3::e] (port=56678 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mugt9-0004QU-Ro; Tue, 07 Dec 2021 15:16:38 -0500 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=a2auO/nwZSDjxRcsqAvT13WhRgORid2rRX6XHDSgGe8=; b=RV34eUmfmRhy XUvqgUeuXvSv7vlU6RGRXrTfDSy0bRFi68j0JqxENkssby1fsnKncMlzdRMOixd3m1ug2c0EukqWK BTjsc67l9kxVeibkbLXECkBpdMBSZjQymHSnIRZScD77dhM9Ty7ks7ViKlgR/mUCQF4f7actXqGZ3 +7InYS8UcvWmnMH3osUI4cy4esXUW0WHB42vQCGBF624QwDRQYHTgaBLdUg5V5+0rosMAPY905j4d et+xOSqr7BE/TxrW+//LrKEKqV0/FRw+AnIW97C1U9xGWWDNwfCAHCpkjHbHHIJ21lw8YhLkCbvtb uPiXJGy5GfllBVNiKfKIkA==; Received: from [87.69.77.57] (port=3511 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mugt9-0005Qi-Km; Tue, 07 Dec 2021 15:16:35 -0500 Date: Tue, 07 Dec 2021 22:16:28 +0200 Message-Id: <83k0ggxjab.fsf@gnu.org> From: Eli Zaretskii To: Alan Mackenzie In-Reply-To: (message from Alan Mackenzie on Tue, 7 Dec 2021 19:58:39 +0000) Subject: Re: bug#52298: 29.0.50; Frequent redisplay cycles induced by c-type-finder-timer-func timer in CC Mode References: <83sfv74hpm.fsf@gnu.org> <83pmq8zi5b.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 52298 Cc: acm@muc.de, 52298@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 (---) > Date: Tue, 7 Dec 2021 19:58:39 +0000 > Cc: 52298@debbugs.gnu.org, acm@muc.de > From: Alan Mackenzie > > > 18 seconds is almost an eternity for my frequent use cases of firing > > up Emacs to debug some display problem. And it's much more than 18 > > sec here: I measured 4 minutes and 21 sec, with 1:54 CPU time. My > > build is unoptimized, but still, a factor of 13 wrt your timing is too > > much to be explained by that alone. > > Is that with xdisp.c the only CC Mode buffer? Yes. Not only the only CC Mode buffer: the only Emacs buffer except 8scratch* and *Messages*. It's "emacs -Q" that just visited xdisp.c. > That 4 minutes 21 seconds - does the thrashing of the redisplay stop > after this amount of uptime? Yes. After that, all I see is the timer running, which forces frequent entries to redisplay (something to remember: frequent timers cause frequent entries to redisplay), but it immediately exits without doing anything. > As a matter of interest, is Emacs responsive to key strokes when this is > happening? It's responsive, but it "stutters": if I lean on the right-arrow key, it doesn't move with uniformly constant velocity, but instead frequently stops for a split-second. > What changes in the buffer is the detection of "foo", "bar", ... as > found types. These get marked throughout the buffer with the fontified > text property set to nil, and if an occurrence is in a displayed window, > that triggers an immediate redisplay to refontify that visible > occurrence of the found type. I think this repeated redisplay is > happening too often. And I think it happens not only for the fontified property set on the visible portion of the buffer, but also on the portions that are outside of the window. In fact, the output of trace-redisplay clearly tells me that redisplay was called when all the changes were after the window's end. Which is expected, given that the window shows the first portion of the file. Is your code using with-silent-modifications, or some other mechanism that should prevent Emacs from thinking that the buffer has changed? If not, why not? From debbugs-submit-bounces@debbugs.gnu.org Wed Dec 08 15:16:07 2021 Received: (at submit) by debbugs.gnu.org; 8 Dec 2021 20:16:07 +0000 Received: from localhost ([127.0.0.1]:41514 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mv3ME-0005VE-Ok for submit@debbugs.gnu.org; Wed, 08 Dec 2021 15:16:07 -0500 Received: from lists.gnu.org ([209.51.188.17]:37484) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mv3M9-0005Uh-Mt for submit@debbugs.gnu.org; Wed, 08 Dec 2021 15:16:05 -0500 Received: from eggs.gnu.org ([209.51.188.92]:50402) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mv3M9-0007ws-H6 for bug-gnu-emacs@gnu.org; Wed, 08 Dec 2021 15:16:01 -0500 Received: from colin.muc.de ([193.149.48.1]:38669 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1mv3M7-00044B-5q for bug-gnu-emacs@gnu.org; Wed, 08 Dec 2021 15:16:01 -0500 Received: (qmail 29853 invoked by uid 3782); 8 Dec 2021 20:15:46 -0000 Received: from acm.muc.de (p4fe15d44.dip0.t-ipconnect.de [79.225.93.68]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Wed, 08 Dec 2021 21:15:46 +0100 Received: (qmail 1201 invoked by uid 1000); 8 Dec 2021 20:15:46 -0000 Date: Wed, 8 Dec 2021 20:15:46 +0000 To: Eli Zaretskii Subject: Re: 29.0.50; Frequent redisplay cycles induced by c-type-finder-timer-func timer in CC Mode Message-ID: References: <83sfv74hpm.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83sfv74hpm.fsf@gnu.org> X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de Received-SPF: pass client-ip=193.149.48.1; envelope-from=acm@muc.de; helo=mail.muc.de X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.6 (-) X-Debbugs-Envelope-To: submit Cc: bug-gnu-emacs@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: -2.6 (--) Hello, Eli. Yes, I've received your more recent posts in this thread. On Sun, Dec 05, 2021 at 09:46:29 +0200, Eli Zaretskii wrote: > It used to be the case that starting "emacs -Q" and disabling > blink-cursor-mode and global-eldoc-mode was enough to get me Emacs > that doesn't perform redisplay unless required. To see this, do the > following with any Emacs up to and including Emacs 28: > emacs -Q > M-x blink-cursor-mode RET > M-x global-eldoc-mode RET > M-x trace-redisplay RET > (The last command is only available if you configured with > "--enable-checking=yes,glyphs".) This would produce a few lines of > output on stderr, and then stop until you do something in Emacs, like > move the cursor with an arrow key. I've just tried building with that ./configure option, and trying out M-x trace-redisplay with emacs -Q on a very recent master version. The command is not very useful on a Linux console. It outputs messages on the same display thing that Emacs itself is using, and outputs them as if they were a Unix text file being naively displayed in Windows: i.e. like this: aaaa aaaaaaaaaaaaa aaaaaaaaaaaaa aaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaa > This is no longer the case in Emacs 29. There, if you visit a C file, > you will see a flurry of stderr messages about constant redisplay > cycles being forced. It seems like the culprit is the function > 'c-type-finder-timer-func', which is run from a timer at 10 Hz (!), > and which for some reason forces Emacs to perform a redisplay cycle > with that frequency. .... I see the flurry of messages. But with trace-redisplay disabled, I see no evidence of excessive redisplay (see below). Could it be that there is some interaction between trace-redisplay and CC Mode which is causing all these redisplayings? > .... The trace itself, viz.: > redisplay_internal 0 > 071a03c8 (xdisp.c): try_window_id 2 > redisplay_preserve_echo_area (8) > means that the processing induced by that timer function is far from > being trivial, which means something that this function does causes > Emacs to think some real change might have happened in the buffer. I'm not familiar with such traces, and trace-redisplay is not documented in its doc string. Could you please explain briefly what the "071a03c8 (xdisp.c):" means, and what says that the processing is non-trivial. Thanks! > Not even "emacs -Q -D" is enough to get rid of this > 'c-type-finder-timer-func' timer in CC Mode buffers. > Is it possible to prevent this frequent timer from firing when no > changes have been done to the buffer? And in any case, please try to > include some logic in that function to avoid whatever it does now to > force such frequent non-trivial redisplay cycles. If nothing else, > laptop users will hate us if we release Emacs with this behavior. When I apply the following patch to cc-fonts.el: diff --git a/lisp/progmodes/cc-fonts.el b/lisp/progmodes/cc-fonts.el index 967464ac14..2ae92f99bf 100644 --- a/lisp/progmodes/cc-fonts.el +++ b/lisp/progmodes/cc-fonts.el @@ -2429,6 +2429,11 @@ c-re-redisplay-timer (defun c-force-redisplay (start end) ;; Force redisplay immediately. This assumes `font-lock-support-mode' is ;; 'jit-lock-mode. Set the variable `c-re-redisplay-timer' to nil. +;;;; TEMPORARY STOUGH, 2021-12-08 + (message "c-force-redisplay - Buffer: %s - %s:%s - \"%s\"" + (buffer-name (current-buffer)) start end + (buffer-substring-no-properties start end)) +;;;; END OF TEMPORARY STOUGH. (save-excursion (c-font-lock-fontify-region start end)) (jit-lock-force-redisplay (copy-marker start) (copy-marker end)) (setq c-re-redisplay-timer nil)) , and load xdisp.c freshly, I see only three lines of output in *Messages*: c-force-redisplay - Buffer: xdisp.c - 223:225 - "it" c-force-redisplay - Buffer: xdisp.c - 49:55 - "buffer" c-force-redisplay - Buffer: xdisp.c - 28:34 - "window" That applies after waiting over a minute. After this time, the `top' utility shows Emacs consuming around 1% of a CPU core's time. All this suggests that in normal use, CC Mode isn't triggering excessive redisplay operations. What am I not seeing? > In GNU Emacs 29.0.50 (build 297, i686-pc-mingw32) > of 2021-12-04 built on HOME-C4E4A596F7 I've checked the git log, and there haven't been any changes to CC Mode since this version. > Repository revision: f247fa5d5ce7cb34f23c979c17b14c5713eb5490 > 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'' [ .... ] -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 09 02:08:40 2021 Received: (at 52298) by debbugs.gnu.org; 9 Dec 2021 07:08:40 +0000 Received: from localhost ([127.0.0.1]:42261 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mvDXj-0005MM-Ua for submit@debbugs.gnu.org; Thu, 09 Dec 2021 02:08:40 -0500 Received: from eggs.gnu.org ([209.51.188.92]:38166) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mvDXi-0005MA-P6 for 52298@debbugs.gnu.org; Thu, 09 Dec 2021 02:08:39 -0500 Received: from [2001:470:142:3::e] (port=60822 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mvDXd-0006MG-De; Thu, 09 Dec 2021 02:08:33 -0500 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=XG3Vfd7lqPdqZb/g/88JK/Dm0GthzKFDTaoKq1Wvv5s=; b=oV7RVqvucddI zrS3N32d4oSKMTYXmV9EfB/tRw1ntRmjj8kQDyqllsK/v5OgRVwMb9AV5HAK6Cbw33sNT3fuxm13D 6epBhzQT1pTxQVDG7FczBF24+lGkQ0KmJOrPiKEibflQuJCHfhN4Oz0Ep7fmtUjP+4kq8PiQRPE3o IvX4suZ0KCqY18Q7w2DTxo5+dnjiorao8tDbPn9WVzrh//s8bXFFiTVr/sXmDqYSe4ZO8cMm5N7IP fexQn1BwJniF0q4jsiRuJpg7GhxjSw7OuBri8/4Wn/VpmFDRhqNi7NBV5xmBny3ajukzYpFs+FFdc WBFLwqziIREYCbLyrSJM6A==; Received: from [87.69.77.57] (port=4178 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mvDXd-0001tE-1i; Thu, 09 Dec 2021 02:08:33 -0500 Date: Thu, 09 Dec 2021 09:08:16 +0200 Message-Id: <83wnkeuufz.fsf@gnu.org> From: Eli Zaretskii To: Alan Mackenzie In-Reply-To: (message from Alan Mackenzie on Wed, 8 Dec 2021 20:15:46 +0000) Subject: bug#52298: 29.0.50; Frequent redisplay cycles induced by c-type-finder-timer-func timer in CC Mode References: <83sfv74hpm.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 52298 Cc: 52298@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 (---) > Date: Wed, 8 Dec 2021 20:15:46 +0000 > Cc: bug-gnu-emacs@gnu.org > From: Alan Mackenzie > > I've just tried building with that ./configure option, and trying out > M-x trace-redisplay with emacs -Q on a very recent master version. > > The command is not very useful on a Linux console. I didn't suggest that you invoke that command, it is not part of this issue. It is just a tool I used to see what's going on, and I do know how to interpret its output. And yes, if your main development environment is based on the Linux console, then many tools will be unavailable to you, but that's a tangent. > It outputs messages > on the same display thing that Emacs itself is using, and outputs them > as if they were a Unix text file being naively displayed in Windows: > i.e. like this: > > aaaa > aaaaaaaaaaaaa > aaaaaaaaaaaaa > aaaaaaaaaaaaaaa > aaaaaaaaaaaaaaaaaa That's not related to Windows, that's because Emacs switches the terminal to a mode where newline doesn't cause the cursor to move to the beginning of the next line. IOW, this is because you are running Emacs on the Linux console and the traces go to the same console, which is not configured to receive simple printf's. > > redisplay_internal 0 > > 071a03c8 (xdisp.c): try_window_id 2 > > redisplay_preserve_echo_area (8) > > > means that the processing induced by that timer function is far from > > being trivial, which means something that this function does causes > > Emacs to think some real change might have happened in the buffer. > > I'm not familiar with such traces, and trace-redisplay is not documented > in its doc string. Could you please explain briefly what the "071a03c8 > (xdisp.c):" means, and what says that the processing is non-trivial. The address and the file name are for when you run under GDB. The important part of that message is "try_window_id 2". If you look in xdisp.c for the trace that emits it, viz.: debug_method_add (w, "try_window_id %d", tem); you will realize that redisplay called try_window_id, which means it was working too hard: since nothing has changed in the buffer, and even point didn't move, it should have succeeded in the call to try_cursor_movement, which is before it. So something prevented try_cursor_movement from succeeding in this case, and kept preventing that for full 4 minutes after the file was visited. The question is: what is that something that causes try_cursor_movement to fail? > > Is it possible to prevent this frequent timer from firing when no > > changes have been done to the buffer? And in any case, please try to > > include some logic in that function to avoid whatever it does now to > > force such frequent non-trivial redisplay cycles. If nothing else, > > laptop users will hate us if we release Emacs with this behavior. > > When I apply the following patch to cc-fonts.el: > > diff --git a/lisp/progmodes/cc-fonts.el b/lisp/progmodes/cc-fonts.el > index 967464ac14..2ae92f99bf 100644 > --- a/lisp/progmodes/cc-fonts.el > +++ b/lisp/progmodes/cc-fonts.el > @@ -2429,6 +2429,11 @@ c-re-redisplay-timer > (defun c-force-redisplay (start end) > ;; Force redisplay immediately. This assumes `font-lock-support-mode' is > ;; 'jit-lock-mode. Set the variable `c-re-redisplay-timer' to nil. > +;;;; TEMPORARY STOUGH, 2021-12-08 > + (message "c-force-redisplay - Buffer: %s - %s:%s - \"%s\"" > + (buffer-name (current-buffer)) start end > + (buffer-substring-no-properties start end)) > +;;;; END OF TEMPORARY STOUGH. > (save-excursion (c-font-lock-fontify-region start end)) > (jit-lock-force-redisplay (copy-marker start) (copy-marker end)) > (setq c-re-redisplay-timer nil)) > > , and load xdisp.c freshly, I see only three lines of output in > *Messages*: > > c-force-redisplay - Buffer: xdisp.c - 223:225 - "it" > c-force-redisplay - Buffer: xdisp.c - 49:55 - "buffer" > c-force-redisplay - Buffer: xdisp.c - 28:34 - "window" > > That applies after waiting over a minute. After this time, the `top' > utility shows Emacs consuming around 1% of a CPU core's time. > > All this suggests that in normal use, CC Mode isn't triggering excessive > redisplay operations. No, it means that your hypothesis regarding what causes the phenomenon was incorrect. Something else prevents try_cursor_movement from successfully deciding that the window doesn't need any redisplay. That something is in the timer function the CC Mode runs. If you can find what that factor is and remove it, it will solve the issue. In a followup message I wrote: > Is your code using with-silent-modifications, or some other mechanism > that should prevent Emacs from thinking that the buffer has changed? > If not, why not? Can you please answer that? It might be the key to unlock this issue, since you said that timer function puts text properties on buffer text. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 09 15:11:42 2021 Received: (at 52298) by debbugs.gnu.org; 9 Dec 2021 20:11:42 +0000 Received: from localhost ([127.0.0.1]:44846 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mvPlW-0000vQ-3s for submit@debbugs.gnu.org; Thu, 09 Dec 2021 15:11:42 -0500 Received: from colin.muc.de ([193.149.48.1]:21547 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1mvPlT-0000vB-Ui for 52298@debbugs.gnu.org; Thu, 09 Dec 2021 15:11:40 -0500 Received: (qmail 1116 invoked by uid 3782); 9 Dec 2021 20:11:33 -0000 Received: from acm.muc.de (p4fe15ce7.dip0.t-ipconnect.de [79.225.92.231]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Thu, 09 Dec 2021 21:11:33 +0100 Received: (qmail 7766 invoked by uid 1000); 9 Dec 2021 20:11:32 -0000 Date: Thu, 9 Dec 2021 20:11:32 +0000 To: Eli Zaretskii Subject: Re: bug#52298: 29.0.50; Frequent redisplay cycles induced by c-type-finder-timer-func timer in CC Mode Message-ID: References: <83sfv74hpm.fsf@gnu.org> <83wnkeuufz.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83wnkeuufz.fsf@gnu.org> X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 52298 Cc: acm@muc.de, 52298@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: -1.0 (-) Hello, Eli. On Thu, Dec 09, 2021 at 09:08:16 +0200, Eli Zaretskii wrote: > > Date: Wed, 8 Dec 2021 20:15:46 +0000 > > Cc: bug-gnu-emacs@gnu.org > > From: Alan Mackenzie > > I've just tried building with that ./configure option, and trying out > > M-x trace-redisplay with emacs -Q on a very recent master version. > > The command is not very useful on a Linux console. > I didn't suggest that you invoke that command, it is not part of this > issue. It is just a tool I used to see what's going on, and I do know > how to interpret its output. Of course. Still, when trace-redisplay is running on my system, the amount of CPU usage is still around 1% of a core for this Emacs. [ .... ] > > > redisplay_internal 0 > > > 071a03c8 (xdisp.c): try_window_id 2 > > > redisplay_preserve_echo_area (8) > > > means that the processing induced by that timer function is far from > > > being trivial, which means something that this function does causes > > > Emacs to think some real change might have happened in the buffer. > > I'm not familiar with such traces, and trace-redisplay is not documented > > in its doc string. Could you please explain briefly what the "071a03c8 > > (xdisp.c):" means, and what says that the processing is non-trivial. > The address and the file name are for when you run under GDB. The > important part of that message is "try_window_id 2". If you look in > xdisp.c for the trace that emits it, viz.: > debug_method_add (w, "try_window_id %d", tem); > you will realize that redisplay called try_window_id, which means it > was working too hard: since nothing has changed in the buffer, and > even point didn't move, it should have succeeded in the call to > try_cursor_movement, which is before it. So something prevented > try_cursor_movement from succeeding in this case, and kept preventing > that for full 4 minutes after the file was visited. The question is: > what is that something that causes try_cursor_movement to fail? The timer function is setting `fontified' text properties to nil. It is doing this inside a with-silent-modifications. (Sorry I didn't answer this question yesterday evening; I should have done.) Have I misunderstood this action? I thought that merely setting the `fontified' text property to nil on a part of the buffer doesn't instantaneously trigger redisplay (except by the calling of after-change-functions, which is here inactive due to `with-silent-modifications'), even if that part of the buffer is currently displayed in a window. If I _have_ misunderstood this, it is very likely the reason for the flurry of redisplayings. I think I need to read bits of xdisp.c rather carefully. [ .... ] > > When I apply the following patch to cc-fonts.el: [ .... ] > > , and load xdisp.c freshly, I see only three lines of output in > > *Messages*: > > c-force-redisplay - Buffer: xdisp.c - 223:225 - "it" > > c-force-redisplay - Buffer: xdisp.c - 49:55 - "buffer" > > c-force-redisplay - Buffer: xdisp.c - 28:34 - "window" > > That applies after waiting over a minute. After this time, the `top' > > utility shows Emacs consuming around 1% of a CPU core's time. > > All this suggests that in normal use, CC Mode isn't triggering excessive > > redisplay operations. > No, it means that your hypothesis regarding what causes the phenomenon > was incorrect. Something else prevents try_cursor_movement from > successfully deciding that the window doesn't need any redisplay. > That something is in the timer function the CC Mode runs. If you can > find what that factor is and remove it, it will solve the issue. OK. I need to understand xdisp.c a little better. > In a followup message I wrote: > > Is your code using with-silent-modifications, or some other mechanism > > that should prevent Emacs from thinking that the buffer has changed? > > If not, why not? > Can you please answer that? It might be the key to unlock this issue, > since you said that timer function puts text properties on buffer > text. Again, the code is indeed using with-silent-modifications, and again, sorry for not saying so yesterday evening. > Thanks. -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 09 15:38:57 2021 Received: (at 52298) by debbugs.gnu.org; 9 Dec 2021 20:38:57 +0000 Received: from localhost ([127.0.0.1]:44877 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mvQBs-0001aS-85 for submit@debbugs.gnu.org; Thu, 09 Dec 2021 15:38:57 -0500 Received: from eggs.gnu.org ([209.51.188.92]:43406) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mvQBq-0001aD-2i for 52298@debbugs.gnu.org; Thu, 09 Dec 2021 15:38:54 -0500 Received: from [2001:470:142:3::e] (port=57440 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mvQBk-0007w3-MN; Thu, 09 Dec 2021 15:38:48 -0500 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=9I2bCdeiLxU6XVsqs9ZblUn3/0lG6ayvGDJhMWcfTSw=; b=pJxS3offceLD OqUY/gJHbphEl8NnSBmVHVYIpibzQ8xuc8/sfajlEIOse0vdlLV+EgcW7sKi5nuSD9JGrdgZTDLJB d0Yw5326zUPqHVT8C/ZP6U3Q5I3jj8+fiiHhmDVPbZbcFVkRAV9+QzZWTgGJNo+6Mg70EldZvI3tW t0ODoVtSVMZfXo1p6Q697QYVeuqBN3qO4FEMV7OCYHUpP1XQgVglgPAAkub6WSKG2J7rO544Pf2dE uCfRi4xFWXj15+TnsQwLfK14/t7cgN5+ruCIrQviBwKoVQytFfvIY1+Q7WSUIAgtmR6zrrtPwYocR T8kt84tGlQy0q0lUviFDAw==; Received: from [87.69.77.57] (port=2688 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mvQBk-0005A4-7o; Thu, 09 Dec 2021 15:38:48 -0500 Date: Thu, 09 Dec 2021 22:38:32 +0200 Message-Id: <838rwttsxj.fsf@gnu.org> From: Eli Zaretskii To: Alan Mackenzie In-Reply-To: (message from Alan Mackenzie on Thu, 9 Dec 2021 20:11:32 +0000) Subject: Re: bug#52298: 29.0.50; Frequent redisplay cycles induced by c-type-finder-timer-func timer in CC Mode References: <83sfv74hpm.fsf@gnu.org> <83wnkeuufz.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 52298 Cc: 52298@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 (---) > Date: Thu, 9 Dec 2021 20:11:32 +0000 > Cc: 52298@debbugs.gnu.org, acm@muc.de > From: Alan Mackenzie > > > debug_method_add (w, "try_window_id %d", tem); > > > you will realize that redisplay called try_window_id, which means it > > was working too hard: since nothing has changed in the buffer, and > > even point didn't move, it should have succeeded in the call to > > try_cursor_movement, which is before it. So something prevented > > try_cursor_movement from succeeding in this case, and kept preventing > > that for full 4 minutes after the file was visited. The question is: > > what is that something that causes try_cursor_movement to fail? > > The timer function is setting `fontified' text properties to nil. It is > doing this inside a with-silent-modifications. (Sorry I didn't answer > this question yesterday evening; I should have done.) > > Have I misunderstood this action? I thought that merely setting the > `fontified' text property to nil on a part of the buffer doesn't > instantaneously trigger redisplay (except by the calling of > after-change-functions, which is here inactive due to > `with-silent-modifications'), even if that part of the buffer is > currently displayed in a window. It seems the reason is not the 'fontified' property, it's the 'c-is-sws' property that c-forward-sws puts on the buffer text. I show the backtrace below. There's also the 'c-type' property that c-get-fontification-context puts; see the second backtrace below. Both of these are called from the timer function. Are they using with-silent-modifications? The result of this is that the buffer's modification tick is increased all the time, and redisplay_window then decides that the current glyph matrix is not up-to-date, which means it must work harder to decide how to redisplay this window. Here are the two backtraces I promised: #0 0x013118d6 in modiff_incr (a=0x6ee5310) at lisp.h:3552 #1 0x0131203e in modify_text_properties (buffer=XIL(0xa000000006ee50a0), start=make_fixnum(39237), end=make_fixnum(39238)) at textprop.c:91 #2 0x01316a2b in add_text_properties_1 (start=make_fixnum(39237), end=make_fixnum(39238), properties=XIL(0xc00000000082b538), object=XIL(0xa000000006ee50a0), set_type=TEXT_PROPERTY_REPLACE, destructive=true) at textprop.c:1224 #3 0x01316ef0 in Fadd_text_properties (start=make_fixnum(39237), end=make_fixnum(39238), properties=XIL(0xc00000000082b538), object=XIL(0)) at textprop.c:1296 #4 0x01316fcf in Fput_text_property (start=make_fixnum(39237), end=make_fixnum(39238), property=XIL(0x56056f0), value=XIL(0x30), object=XIL(0)) at textprop.c:1314 #5 0x012670c5 in funcall_subr (subr=0x17216a0 , numargs=4, args=0x82b790) at eval.c:3152 #6 0x012669b1 in Ffuncall (nargs=5, args=0x82b788) at eval.c:3065 #7 0x012d3314 in exec_byte_code (bytestr=XIL(0x8000000006e55e40), vector=XIL(0xa000000006e55068), maxdepth=make_fixnum(19), args_template=make_fixnum(0), nargs=0, args=0x82c0a8) at bytecode.c:632 #8 0x012674f6 in fetch_and_exec_byte_code (fun=XIL(0xa000000006e551e8), syms_left=make_fixnum(0), nargs=0, args=0x82c0a8) at eval.c:3189 #9 0x01267a73 in funcall_lambda (fun=XIL(0xa000000006e551e8), nargs=0, arg_vector=0x82c0a8) at eval.c:3270 #10 0x01266a21 in Ffuncall (nargs=1, args=0x82c0a0) at eval.c:3069 #11 0x012d3314 in exec_byte_code (bytestr=XIL(0x80000000074e9df8), vector=XIL(0xa0000000074e1888), maxdepth=make_fixnum(14), args_template=make_fixnum(257), nargs=1, args=0x82c7e0) at bytecode.c:632 #12 0x012674f6 in fetch_and_exec_byte_code (fun=XIL(0xa0000000074e1990), syms_left=make_fixnum(257), nargs=1, args=0x82c7d8) at eval.c:3189 #13 0x01267a73 in funcall_lambda (fun=XIL(0xa0000000074e1990), nargs=1, arg_vector=0x82c7d8) at eval.c:3270 #14 0x01266a21 in Ffuncall (nargs=2, args=0x82c7d0) at eval.c:3069 #15 0x012d3314 in exec_byte_code (bytestr=XIL(0x8000000006eedf18), vector=XIL(0xa0000000074e1b58), maxdepth=make_fixnum(7), args_template=make_fixnum(514), nargs=2, args=0x82cde0) at bytecode.c:632 #16 0x012674f6 in fetch_and_exec_byte_code (fun=XIL(0xa0000000074e1bc8), syms_left=make_fixnum(514), nargs=2, args=0x82cdd0) at eval.c:3189 #17 0x01267a73 in funcall_lambda (fun=XIL(0xa0000000074e1bc8), nargs=2, arg_vector=0x82cdd0) at eval.c:3270 #18 0x01266a21 in Ffuncall (nargs=3, args=0x82cdc8) at eval.c:3069 #19 0x012d3314 in exec_byte_code (bytestr=XIL(0x8000000006eedf48), vector=XIL(0xa00000000753e690), maxdepth=make_fixnum(5), args_template=make_fixnum(257), nargs=1, args=0x82d390) at bytecode.c:632 #20 0x012674f6 in fetch_and_exec_byte_code (fun=XIL(0xa00000000753e6b0), syms_left=make_fixnum(257), nargs=1, args=0x82d388) at eval.c:3189 #21 0x01267a73 in funcall_lambda (fun=XIL(0xa00000000753e6b0), nargs=1, arg_vector=0x82d388) at eval.c:3270 #22 0x01266a21 in Ffuncall (nargs=2, args=0x82d380) at eval.c:3069 #23 0x01265cc4 in call1 (fn=XIL(0xa00000000753e6b0), arg1=XIL(0x5c690a0)) at eval.c:2925 #24 0x0127bd8f in mapcar1 (leni=1, vals=0x0, fn=XIL(0xa00000000753e6b0), seq=XIL(0xc000000006f4fe30)) at fns.c:2848 #25 0x0127c4eb in Fmapc (function=XIL(0xa00000000753e6b0), sequence=XIL(0xc000000006f4fe30)) at fns.c:2925 #26 0x01266f6c in funcall_subr (subr=0x171fa20 , numargs=2, args=0x82d688) at eval.c:3142 #27 0x012669b1 in Ffuncall (nargs=3, args=0x82d680) at eval.c:3065 #28 0x012d3314 in exec_byte_code (bytestr=XIL(0x8000000006eedf38), vector=XIL(0xa0000000074e1c48), maxdepth=make_fixnum(11), args_template=make_fixnum(514), nargs=2, args=0x82dca0) at bytecode.c:632 #29 0x012674f6 in fetch_and_exec_byte_code (fun=XIL(0xa0000000074e1c70), syms_left=make_fixnum(514), nargs=2, args=0x82dc90) at eval.c:3189 #30 0x01267a73 in funcall_lambda (fun=XIL(0xa0000000074e1c70), nargs=2, arg_vector=0x82dc90) at eval.c:3270 #31 0x01266a21 in Ffuncall (nargs=3, args=0x82dc88) at eval.c:3069 #32 0x012d3314 in exec_byte_code (bytestr=XIL(0x80000000074a3398), vector=XIL(0xa000000006f6c918), maxdepth=make_fixnum(11), args_template=make_fixnum(0), nargs=0, args=0x82e530) at bytecode.c:632 #33 0x012674f6 in fetch_and_exec_byte_code (fun=XIL(0xa000000006f37d58), syms_left=make_fixnum(0), nargs=0, args=0x82e530) at eval.c:3189 #34 0x01267a73 in funcall_lambda (fun=XIL(0xa000000006f37d58), nargs=0, arg_vector=0x82e530) at eval.c:3270 #35 0x01266a21 in Ffuncall (nargs=1, args=0x82e528) at eval.c:3069 #36 0x01264f28 in Fapply (nargs=2, args=0x82e528) at eval.c:2648 #37 0x01266e59 in funcall_subr (subr=0x171eda0 , numargs=2, args=0x82e528) at eval.c:3120 #38 0x012669b1 in Ffuncall (nargs=3, args=0x82e520) at eval.c:3065 #39 0x012d3314 in exec_byte_code (bytestr=XIL(0x80000000061333c4), vector=XIL(0xa000000006133294), maxdepth=make_fixnum(10), args_template=make_fixnum(257), nargs=1, args=0x82ebb0) at bytecode.c:632 #40 0x012674f6 in fetch_and_exec_byte_code (fun=XIL(0xa000000006133264), syms_left=make_fixnum(257), nargs=1, args=0x82eba8) at eval.c:3189 #41 0x01267a73 in funcall_lambda (fun=XIL(0xa000000006133264), nargs=1, arg_vector=0x82eba8) at eval.c:3270 #42 0x01266a21 in Ffuncall (nargs=2, args=0x82eba0) at eval.c:3069 #43 0x01265cc4 in call1 (fn=XIL(0xf120), arg1=XIL(0xa00000000753e580)) at eval.c:2925 #44 0x0117447a in timer_check_2 (timers=XIL(0), idle_timers=XIL(0)) at keyboard.c:4374 #45 0x01174675 in timer_check () at keyboard.c:4436 #46 0x01171ed6 in readable_events (flags=1) at keyboard.c:3448 #47 0x0117c519 in get_input_pending (flags=1) at keyboard.c:6924 #48 0x0118878d in detect_input_pending_run_timers (do_display=false) at keyboard.c:10454 #49 0x0116e798 in read_char (commandflag=1, map=XIL(0xc000000007629a30), prev_event=XIL(0), used_mouse_menu=0x82f45f, end_time=0x0) at keyboard.c:2813 #50 0x01185e58 in read_key_sequence (keybuf=0x82f760, prompt=XIL(0), dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false) at keyboard.c:9631 #51 0x0116924a in command_loop_1 () at keyboard.c:1393 #52 0x0126082e in internal_condition_case (bfun=0x1168b27 , handlers=XIL(0x90), hfun=0x1167b25 ) at eval.c:1492 #53 0x01168594 in command_loop_2 (handlers=XIL(0x90)) at keyboard.c:1134 #54 0x0125f6bf in internal_catch (tag=XIL(0xf3f0), func=0x116855d , arg=XIL(0x90)) at eval.c:1223 #55 0x01168517 in command_loop () at keyboard.c:1112 #56 0x0116758d in recursive_edit_1 () at keyboard.c:721 #57 0x01167823 in Frecursive_edit () at keyboard.c:804 #58 0x01162e9f in main (argc=2, argv=0xa42a10) at emacs.c:2409 Lisp Backtrace: "put-text-property" (0x82b790) "c-forward-sws" (0x82c0a8) "c-fl-decl-start" (0x82c7d8) "c-context-expand-fl-region" (0x82cdd0) 0x753e6b0 PVEC_COMPILED "mapc" (0x82d688) "c-before-context-fl-expand-region" (0x82dc90) "c-type-finder-timer-func" (0x82e530) "apply" (0x82e528) "timer-event-handler" (0x82eba8) (gdb) fr 4 #4 0x01316fcf in Fput_text_property (start=make_fixnum(39237), end=make_fixnum(39238), property=XIL(0x56056f0), value=XIL(0x30), object=XIL(0)) at textprop.c:1314 1314 Fadd_text_properties (start, end, properties, object); (gdb) pp property c-is-sws ---------------------------------------------------------------------- #0 0x013118d6 in modiff_incr (a=0x6ee5310) at lisp.h:3552 #1 0x0131203e in modify_text_properties (buffer=XIL(0xa000000006ee50a0), start=make_fixnum(39339), end=make_fixnum(39340)) at textprop.c:91 #2 0x01316a2b in add_text_properties_1 (start=make_fixnum(39339), end=make_fixnum(39340), properties=XIL(0xc00000000082b258), object=XIL(0xa000000006ee50a0), set_type=TEXT_PROPERTY_REPLACE, destructive=true) at textprop.c:1224 #3 0x01316ef0 in Fadd_text_properties (start=make_fixnum(39339), end=make_fixnum(39340), properties=XIL(0xc00000000082b258), object=XIL(0)) at textprop.c:1296 #4 0x01316fcf in Fput_text_property (start=make_fixnum(39339), end=make_fixnum(39340), property=XIL(0x57a2ff8), value=XIL(0x566adc8), object=XIL(0)) at textprop.c:1314 #5 0x012670c5 in funcall_subr (subr=0x17216a0 , numargs=4, args=0x82b478) at eval.c:3152 #6 0x012669b1 in Ffuncall (nargs=5, args=0x82b470) at eval.c:3065 #7 0x012d3314 in exec_byte_code (bytestr=XIL(0x80000000074a3208), vector=XIL(0xa000000006f37550), maxdepth=make_fixnum(10), args_template=make_fixnum(770), nargs=3, args=0x82bca0) at bytecode.c:632 #8 0x012674f6 in fetch_and_exec_byte_code (fun=XIL(0xa000000006f376e8), syms_left=make_fixnum(770), nargs=3, args=0x82bc88) at eval.c:3189 #9 0x01267a73 in funcall_lambda (fun=XIL(0xa000000006f376e8), nargs=3, arg_vector=0x82bc88) at eval.c:3270 #10 0x01266a21 in Ffuncall (nargs=4, args=0x82bc80) at eval.c:3069 #11 0x012d3314 in exec_byte_code (bytestr=XIL(0x80000000074a3348), vector=XIL(0xa000000007581b18), maxdepth=make_fixnum(8), args_template=make_fixnum(770), nargs=3, args=0x82c348) at bytecode.c:632 #12 0x012674f6 in fetch_and_exec_byte_code (fun=XIL(0xa000000007581bc8), syms_left=make_fixnum(770), nargs=3, args=0x82c330) at eval.c:3189 #13 0x01267a73 in funcall_lambda (fun=XIL(0xa000000007581bc8), nargs=3, arg_vector=0x82c330) at eval.c:3270 #14 0x01266a21 in Ffuncall (nargs=4, args=0x82c328) at eval.c:3069 #15 0x012d3314 in exec_byte_code (bytestr=XIL(0x8000000006f7a9f0), vector=XIL(0xa0000000065a7a50), maxdepth=make_fixnum(23), args_template=make_fixnum(1028), nargs=4, args=0x82d658) at bytecode.c:632 #16 0x012674f6 in fetch_and_exec_byte_code (fun=XIL(0xa0000000065a7c68), syms_left=make_fixnum(1028), nargs=4, args=0x82d638) at eval.c:3189 #17 0x01267a73 in funcall_lambda (fun=XIL(0xa0000000065a7c68), nargs=4, arg_vector=0x82d638) at eval.c:3270 #18 0x01266a21 in Ffuncall (nargs=5, args=0x82d630) at eval.c:3069 #19 0x012d3314 in exec_byte_code (bytestr=XIL(0x80000000074a3338), vector=XIL(0xa000000006f37c50), maxdepth=make_fixnum(18), args_template=make_fixnum(514), nargs=2, args=0x82dca8) at bytecode.c:632 #20 0x012674f6 in fetch_and_exec_byte_code (fun=XIL(0xa000000006f37c98), syms_left=make_fixnum(514), nargs=2, args=0x82dc98) at eval.c:3189 #21 0x01267a73 in funcall_lambda (fun=XIL(0xa000000006f37c98), nargs=2, arg_vector=0x82dc98) at eval.c:3270 #22 0x01266a21 in Ffuncall (nargs=3, args=0x82dc90) at eval.c:3069 #23 0x012d3314 in exec_byte_code (bytestr=XIL(0x80000000074a3398), vector=XIL(0xa000000006f6c918), maxdepth=make_fixnum(11), args_template=make_fixnum(0), nargs=0, args=0x82e530) at bytecode.c:632 #24 0x012674f6 in fetch_and_exec_byte_code (fun=XIL(0xa000000006f37d58), syms_left=make_fixnum(0), nargs=0, args=0x82e530) at eval.c:3189 #25 0x01267a73 in funcall_lambda (fun=XIL(0xa000000006f37d58), nargs=0, arg_vector=0x82e530) at eval.c:3270 #26 0x01266a21 in Ffuncall (nargs=1, args=0x82e528) at eval.c:3069 #27 0x01264f28 in Fapply (nargs=2, args=0x82e528) at eval.c:2648 #28 0x01266e59 in funcall_subr (subr=0x171eda0 , numargs=2, args=0x82e528) at eval.c:3120 #29 0x012669b1 in Ffuncall (nargs=3, args=0x82e520) at eval.c:3065 #30 0x012d3314 in exec_byte_code (bytestr=XIL(0x80000000061333c4), vector=XIL(0xa000000006133294), maxdepth=make_fixnum(10), args_template=make_fixnum(257), nargs=1, args=0x82ebb0) at bytecode.c:632 #31 0x012674f6 in fetch_and_exec_byte_code (fun=XIL(0xa000000006133264), syms_left=make_fixnum(257), nargs=1, args=0x82eba8) at eval.c:3189 #32 0x01267a73 in funcall_lambda (fun=XIL(0xa000000006133264), nargs=1, arg_vector=0x82eba8) at eval.c:3270 #33 0x01266a21 in Ffuncall (nargs=2, args=0x82eba0) at eval.c:3069 #34 0x01265cc4 in call1 (fn=XIL(0xf120), arg1=XIL(0xa00000000753e580)) at eval.c:2925 #35 0x0117447a in timer_check_2 (timers=XIL(0), idle_timers=XIL(0)) at keyboard.c:4374 #36 0x01174675 in timer_check () at keyboard.c:4436 #37 0x01171ed6 in readable_events (flags=1) at keyboard.c:3448 #38 0x0117c519 in get_input_pending (flags=1) at keyboard.c:6924 #39 0x0118878d in detect_input_pending_run_timers (do_display=false) at keyboard.c:10454 #40 0x0116e798 in read_char (commandflag=1, map=XIL(0xc000000007629a30), prev_event=XIL(0), used_mouse_menu=0x82f45f, end_time=0x0) at keyboard.c:2813 #41 0x01185e58 in read_key_sequence (keybuf=0x82f760, prompt=XIL(0), dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false) at keyboard.c:9631 #42 0x0116924a in command_loop_1 () at keyboard.c:1393 #43 0x0126082e in internal_condition_case (bfun=0x1168b27 , handlers=XIL(0x90), hfun=0x1167b25 ) at eval.c:1492 #44 0x01168594 in command_loop_2 (handlers=XIL(0x90)) at keyboard.c:1134 #45 0x0125f6bf in internal_catch (tag=XIL(0xf3f0), func=0x116855d , arg=XIL(0x90)) at eval.c:1223 #46 0x01168517 in command_loop () at keyboard.c:1112 #47 0x0116758d in recursive_edit_1 () at keyboard.c:721 #48 0x01167823 in Frecursive_edit () at keyboard.c:804 #49 0x01162e9f in main (argc=2, argv=0xa42a10) at emacs.c:2409 Lisp Backtrace: "put-text-property" (0x82b478) "c-get-fontification-context" (0x82bc88) 0x7581bc8 PVEC_COMPILED "c-find-decl-spots" (0x82d638) "c-find-types-background" (0x82dc98) "c-type-finder-timer-func" (0x82e530) "apply" (0x82e528) "timer-event-handler" (0x82eba8) (gdb) fr 4 #4 0x01316fcf in Fput_text_property (start=make_fixnum(39339), end=make_fixnum(39340), property=XIL(0x57a2ff8), value=XIL(0x566adc8), object=XIL(0)) at textprop.c:1314 1314 Fadd_text_properties (start, end, properties, object); (gdb) pp property c-type From debbugs-submit-bounces@debbugs.gnu.org Fri Dec 10 13:16:29 2021 Received: (at 52298) by debbugs.gnu.org; 10 Dec 2021 18:16:29 +0000 Received: from localhost ([127.0.0.1]:47891 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mvkRZ-0007xG-1T for submit@debbugs.gnu.org; Fri, 10 Dec 2021 13:16:29 -0500 Received: from colin.muc.de ([193.149.48.1]:56596 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1mvkRX-0007x1-QS for 52298@debbugs.gnu.org; Fri, 10 Dec 2021 13:16:28 -0500 Received: (qmail 90697 invoked by uid 3782); 10 Dec 2021 18:16:21 -0000 Received: from acm.muc.de (p4fe15e51.dip0.t-ipconnect.de [79.225.94.81]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Fri, 10 Dec 2021 19:16:21 +0100 Received: (qmail 7044 invoked by uid 1000); 10 Dec 2021 18:16:21 -0000 Date: Fri, 10 Dec 2021 18:16:21 +0000 To: Eli Zaretskii Subject: Re: bug#52298: 29.0.50; Frequent redisplay cycles induced by c-type-finder-timer-func timer in CC Mode Message-ID: References: <83sfv74hpm.fsf@gnu.org> <83wnkeuufz.fsf@gnu.org> <838rwttsxj.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <838rwttsxj.fsf@gnu.org> X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 52298 Cc: acm@muc.de, 52298@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: -1.0 (-) Hello, Eli. On Thu, Dec 09, 2021 at 22:38:32 +0200, Eli Zaretskii wrote: > > Date: Thu, 9 Dec 2021 20:11:32 +0000 > > Cc: 52298@debbugs.gnu.org, acm@muc.de > > From: Alan Mackenzie [ .... ] > It seems the reason is not the 'fontified' property, it's the > 'c-is-sws' property that c-forward-sws puts on the buffer text. I > show the backtrace below. There's also the 'c-type' property that > c-get-fontification-context puts; see the second backtrace below. Thanks for the debugging! > Both of these are called from the timer function. Are they using > with-silent-modifications? I'm pretty sure they are. I think that modify_text_properties is calling modiff_incr even when inhibit_modification_hooks is non-nil. I tried putting an `if' around that bit of the code, without any great success. The main reason for all the redisplaying (which I got from trace-redisplay displaying "redisplay_preserve_echo_area (8)") is the call from detect_input_pending_run_timers in keyboard.c. It is calling redisplay_preserve_echo_area each time the timer triggers. The call to detect_input_pending_run_timers (true) (that argument being `do_display') seems to be in dispnew.c, assuming it's not in process.c. I'll need to look further into this. > The result of this is that the buffer's modification tick is increased > all the time, and redisplay_window then decides that the current glyph > matrix is not up-to-date, which means it must work harder to decide > how to redisplay this window. > Here are the two backtraces I promised: > #0 0x013118d6 in modiff_incr (a=0x6ee5310) at lisp.h:3552 > #1 0x0131203e in modify_text_properties (buffer=XIL(0xa000000006ee50a0), > start=make_fixnum(39237), end=make_fixnum(39238)) at textprop.c:91 > #2 0x01316a2b in add_text_properties_1 (start=make_fixnum(39237), > end=make_fixnum(39238), properties=XIL(0xc00000000082b538), > object=XIL(0xa000000006ee50a0), set_type=TEXT_PROPERTY_REPLACE, > destructive=true) at textprop.c:1224 > #3 0x01316ef0 in Fadd_text_properties (start=make_fixnum(39237), > end=make_fixnum(39238), properties=XIL(0xc00000000082b538), object=XIL(0)) > at textprop.c:1296 > #4 0x01316fcf in Fput_text_property (start=make_fixnum(39237), > end=make_fixnum(39238), property=XIL(0x56056f0), value=XIL(0x30), > object=XIL(0)) at textprop.c:1314 > #5 0x012670c5 in funcall_subr (subr=0x17216a0 , > numargs=4, args=0x82b790) at eval.c:3152 [ .... ] > Lisp Backtrace: > "put-text-property" (0x82b790) > "c-forward-sws" (0x82c0a8) > "c-fl-decl-start" (0x82c7d8) > "c-context-expand-fl-region" (0x82cdd0) > 0x753e6b0 PVEC_COMPILED > "mapc" (0x82d688) > "c-before-context-fl-expand-region" (0x82dc90) > "c-type-finder-timer-func" (0x82e530) > "apply" (0x82e528) > "timer-event-handler" (0x82eba8) > ---------------------------------------------------------------------- > #0 0x013118d6 in modiff_incr (a=0x6ee5310) at lisp.h:3552 > #1 0x0131203e in modify_text_properties (buffer=XIL(0xa000000006ee50a0), > start=make_fixnum(39339), end=make_fixnum(39340)) at textprop.c:91 > #2 0x01316a2b in add_text_properties_1 (start=make_fixnum(39339), > end=make_fixnum(39340), properties=XIL(0xc00000000082b258), > object=XIL(0xa000000006ee50a0), set_type=TEXT_PROPERTY_REPLACE, > destructive=true) at textprop.c:1224 > #3 0x01316ef0 in Fadd_text_properties (start=make_fixnum(39339), > end=make_fixnum(39340), properties=XIL(0xc00000000082b258), object=XIL(0)) > at textprop.c:1296 > #4 0x01316fcf in Fput_text_property (start=make_fixnum(39339), > end=make_fixnum(39340), property=XIL(0x57a2ff8), value=XIL(0x566adc8), > object=XIL(0)) at textprop.c:1314 > #5 0x012670c5 in funcall_subr (subr=0x17216a0 , > numargs=4, args=0x82b478) at eval.c:3152 [ .... ] > Lisp Backtrace: > "put-text-property" (0x82b478) > "c-get-fontification-context" (0x82bc88) > 0x7581bc8 PVEC_COMPILED > "c-find-decl-spots" (0x82d638) > "c-find-types-background" (0x82dc98) > "c-type-finder-timer-func" (0x82e530) > "apply" (0x82e528) > "timer-event-handler" (0x82eba8) > (gdb) fr 4 > #4 0x01316fcf in Fput_text_property (start=make_fixnum(39339), > end=make_fixnum(39340), property=XIL(0x57a2ff8), value=XIL(0x566adc8), > object=XIL(0)) at textprop.c:1314 > 1314 Fadd_text_properties (start, end, properties, object); > (gdb) pp property > c-type -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Fri Dec 10 13:51:57 2021 Received: (at 52298) by debbugs.gnu.org; 10 Dec 2021 18:51:57 +0000 Received: from localhost ([127.0.0.1]:47904 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mvkzt-0000To-Ah for submit@debbugs.gnu.org; Fri, 10 Dec 2021 13:51:57 -0500 Received: from eggs.gnu.org ([209.51.188.92]:38612) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mvkzp-0000TX-Jo for 52298@debbugs.gnu.org; Fri, 10 Dec 2021 13:51:55 -0500 Received: from [2001:470:142:3::e] (port=43546 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mvkzi-0006oJ-Ts; Fri, 10 Dec 2021 13:51:46 -0500 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=RCz00MxglATJhWjTd6sF0I8NJFzEgs1M8fp0Lefyw+o=; b=fNve3dkES1Ia Mgsp/Y1QM/u0neuGSO3TzChfwDSUtAMfJJ5+u/UxI29oSVaVel45IHvp1+1gNJMXAC5nx8zOvfknQ KGP+DHZgHEM+BDyV2ayI0U0KMhk896t7nqicAhnwJ4WnQL+r52CEcQ33y4cRJ8lTXG2L0JC9m9292 SBtlZ8bF9pGWtPMxjFfC/i28BzqGpRi6DoHSQO4SmQmdf0hj1pJfnGdDlAGFLt6k073Lgh5VsUPYN i1qO1BUwxptjW1qChCByEdyV8St2STVipaVtOY3EZ2xb1S4ZEOxQq0KZQ3HXbttx5rbNnTq2NEle8 qfK89cVlxYSsU1+ItAkFdg==; Received: from [87.69.77.57] (port=4806 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mvkzh-0001R2-OX; Fri, 10 Dec 2021 13:51:46 -0500 Date: Fri, 10 Dec 2021 20:51:32 +0200 Message-Id: <838rwss37v.fsf@gnu.org> From: Eli Zaretskii To: Alan Mackenzie In-Reply-To: (message from Alan Mackenzie on Fri, 10 Dec 2021 18:16:21 +0000) Subject: Re: bug#52298: 29.0.50; Frequent redisplay cycles induced by c-type-finder-timer-func timer in CC Mode References: <83sfv74hpm.fsf@gnu.org> <83wnkeuufz.fsf@gnu.org> <838rwttsxj.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 52298 Cc: acm@muc.de, 52298@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 (---) > Date: Fri, 10 Dec 2021 18:16:21 +0000 > Cc: 52298@debbugs.gnu.org, acm@muc.de > From: Alan Mackenzie > > > Both of these are called from the timer function. Are they using > > with-silent-modifications? > > I'm pretty sure they are. > > I think that modify_text_properties is calling modiff_incr even when > inhibit_modification_hooks is non-nil. I tried putting an `if' around > that bit of the code, without any great success. AFAIK, with-silent-modifications is supposed to prevent BUF_MODIFF from increasing. Are you sure you see that? And what kind of 'if' did you try to put and where? > The main reason for all the redisplaying (which I got from > trace-redisplay displaying "redisplay_preserve_echo_area (8)") is the > call from detect_input_pending_run_timers in keyboard.c. It is calling > redisplay_preserve_echo_area each time the timer triggers. This is normal, not something you need to investigate: every time a timer function fires, we make one more iteration through the Emacs idle loop, and that includes a call to redisplay_preserve_echo_area. Once again, the problem is not that redisplay is invoked, the problem is that it doesn't exit almost immediately, after detecting that nothing's changed. From debbugs-submit-bounces@debbugs.gnu.org Fri Dec 10 17:52:50 2021 Received: (at 52298) by debbugs.gnu.org; 10 Dec 2021 22:52:50 +0000 Received: from localhost ([127.0.0.1]:48173 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mvokz-0006NA-RU for submit@debbugs.gnu.org; Fri, 10 Dec 2021 17:52:50 -0500 Received: from colin.muc.de ([193.149.48.1]:64151 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1mvokx-0006Mw-Rn for 52298@debbugs.gnu.org; Fri, 10 Dec 2021 17:52:48 -0500 Received: (qmail 70735 invoked by uid 3782); 10 Dec 2021 22:52:41 -0000 Received: from acm.muc.de (p4fe15e51.dip0.t-ipconnect.de [79.225.94.81]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Fri, 10 Dec 2021 23:52:41 +0100 Received: (qmail 10381 invoked by uid 1000); 10 Dec 2021 22:52:40 -0000 Date: Fri, 10 Dec 2021 22:52:40 +0000 To: Eli Zaretskii Subject: Re: bug#52298: 29.0.50; Frequent redisplay cycles induced by c-type-finder-timer-func timer in CC Mode Message-ID: References: <83sfv74hpm.fsf@gnu.org> <83wnkeuufz.fsf@gnu.org> <838rwttsxj.fsf@gnu.org> <838rwss37v.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <838rwss37v.fsf@gnu.org> X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 52298 Cc: acm@muc.de, 52298@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: -1.0 (-) Hello, Eli. On Fri, Dec 10, 2021 at 20:51:32 +0200, Eli Zaretskii wrote: > > Date: Fri, 10 Dec 2021 18:16:21 +0000 > > Cc: 52298@debbugs.gnu.org, acm@muc.de > > From: Alan Mackenzie > > > Both of these are called from the timer function. Are they using > > > with-silent-modifications? > > I'm pretty sure they are. > > I think that modify_text_properties is calling modiff_incr even when > > inhibit_modification_hooks is non-nil. I tried putting an `if' around > > that bit of the code, without any great success. > AFAIK, with-silent-modifications is supposed to prevent BUF_MODIFF > from increasing. I don't think it does in the modify_text_properties case. > Are you sure you see that? And what kind of 'if' did you try to put > and where? In modify_text_properties, around the modiff_incr bit: diff --git a/src/textprop.c b/src/textprop.c index d7d6a66923..d91b8624ef 100644 --- a/src/textprop.c +++ b/src/textprop.c @@ -85,10 +85,13 @@ modify_text_properties (Lisp_Object buffer, Lisp_Object start, Lisp_Object end) prepare_to_modify_buffer_1 (b, e, NULL); - BUF_COMPUTE_UNCHANGED (buf, b - 1, e); - if (MODIFF <= SAVE_MODIFF) - record_first_change (); - modiff_incr (&MODIFF); + if (!inhibit_modification_hooks) + { + BUF_COMPUTE_UNCHANGED (buf, b - 1, e); + if (MODIFF <= SAVE_MODIFF) + record_first_change (); + modiff_incr (&MODIFF); + } bset_point_before_scroll (current_buffer, Qnil); > > The main reason for all the redisplaying (which I got from > > trace-redisplay displaying "redisplay_preserve_echo_area (8)") is the > > call from detect_input_pending_run_timers in keyboard.c. It is calling > > redisplay_preserve_echo_area each time the timer triggers. > This is normal, not something you need to investigate: every time a > timer function fires, we make one more iteration through the Emacs > idle loop, and that includes a call to redisplay_preserve_echo_area. Ah, OK. > Once again, the problem is not that redisplay is invoked, the problem > is that it doesn't exit almost immediately, after detecting that > nothing's changed. I'm again not entirely convinced we have a problem. When trace-redisplay is enabled on my machine, and xdisp.c visited, Emacs uses between 20% and 25% of one CPU core for a little under 2 minutes (a 4½ year old Ryzen). After this it is down to 0.3%. All the time it is outputting trace-redisplay messages, two I think for each timer iteration. I'm a bit surprised at the moment it's taking so long to do the initial found-type scanning, but it's not all that bad. The --enable-cheking=yes,glyphs will have slowed the machine down somewhat. One refinement would be to turn off the timer when All the CC Mode buffers have been scanned, only reenabling it when a new CC Mode buffer gets loaded. That might save that 0.3% core time at the end of the found-type scan. -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Sat Dec 11 02:59:59 2021 Received: (at 52298) by debbugs.gnu.org; 11 Dec 2021 07:59:59 +0000 Received: from localhost ([127.0.0.1]:48442 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mvxIU-0003Fq-Rs for submit@debbugs.gnu.org; Sat, 11 Dec 2021 02:59:59 -0500 Received: from eggs.gnu.org ([209.51.188.92]:59514) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mvxIS-0003Fd-G4 for 52298@debbugs.gnu.org; Sat, 11 Dec 2021 02:59:57 -0500 Received: from [2001:470:142:3::e] (port=49034 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mvxIL-00031x-VL; Sat, 11 Dec 2021 02:59:49 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=5lGg52AFj3MKDNmWHutFKd+nEuDCVHccTdYbhB4sHBk=; b=a4JTH+Kkkc8cz2+wHN9p BR02eUyDTjSwa5IToEjXcXdCVOw3Vdak/G8VkQ1PZtbHeZfX0Ru+4/dy3Wav8lQCKxr5tiou+04Sm yHk+Y6yHzV7+4yMbcAU5hM78H+0VJ2ookM5P6lXYXMfkjWVaOryeNcD59kHjAfeJHxIR6XhiS5Jf0 x6mDaA2dvXijzyFbKx2aZjbt3g18REWmigKTplNEZIrkU4JLqSERIozK6eotvlHro5NMqfu2j+Uou FW9P1Y/WOMSUUTHZTBhZapIAZwcYKWKhq/ECTGvFN+6AzT/MewlLTlLXkKcdzI+udy/RTPVikS3cp az77ZZQAz9QtAQ==; Received: from [87.69.77.57] (port=1213 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mvxIL-00080y-PW; Sat, 11 Dec 2021 02:59:50 -0500 Date: Sat, 11 Dec 2021 09:59:38 +0200 Message-Id: <83tuffr2qd.fsf@gnu.org> From: Eli Zaretskii To: Alan Mackenzie In-Reply-To: (message from Alan Mackenzie on Fri, 10 Dec 2021 22:52:40 +0000) Subject: Re: bug#52298: 29.0.50; Frequent redisplay cycles induced by c-type-finder-timer-func timer in CC Mode References: <83sfv74hpm.fsf@gnu.org> <83wnkeuufz.fsf@gnu.org> <838rwttsxj.fsf@gnu.org> <838rwss37v.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 52298 Cc: 52298@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 (---) > Date: Fri, 10 Dec 2021 22:52:40 +0000 > Cc: 52298@debbugs.gnu.org, acm@muc.de > From: Alan Mackenzie > > > > I think that modify_text_properties is calling modiff_incr even when > > > inhibit_modification_hooks is non-nil. I tried putting an `if' around > > > that bit of the code, without any great success. > > > AFAIK, with-silent-modifications is supposed to prevent BUF_MODIFF > > from increasing. > > I don't think it does in the modify_text_properties case. Maybe I'm misremembering. But let me ask you why those 2 text properties are involved in this case, and what do they signify? Could we perhaps refrain from putting them on buffer text when those functions are called from the timer? And why does that timer have to tick so frequently? > > Are you sure you see that? And what kind of 'if' did you try to put > > and where? > > In modify_text_properties, around the modiff_incr bit: > > diff --git a/src/textprop.c b/src/textprop.c > index d7d6a66923..d91b8624ef 100644 > --- a/src/textprop.c > +++ b/src/textprop.c > @@ -85,10 +85,13 @@ modify_text_properties (Lisp_Object buffer, > Lisp_Object start, Lisp_Object end) > > prepare_to_modify_buffer_1 (b, e, NULL); > > - BUF_COMPUTE_UNCHANGED (buf, b - 1, e); > - if (MODIFF <= SAVE_MODIFF) > - record_first_change (); > - modiff_incr (&MODIFF); > + if (!inhibit_modification_hooks) > + { > + BUF_COMPUTE_UNCHANGED (buf, b - 1, e); > + if (MODIFF <= SAVE_MODIFF) > + record_first_change (); > + modiff_incr (&MODIFF); > + } And modiff_incr is still being called? How's that possible, unless you don't use with-silent-modifications when you put those 2 properties? Or maybe modiff_incr is called from some other place as well? > > Once again, the problem is not that redisplay is invoked, the problem > > is that it doesn't exit almost immediately, after detecting that > > nothing's changed. > > I'm again not entirely convinced we have a problem. When trace-redisplay > is enabled on my machine, and xdisp.c visited, Emacs uses between 20% and > 25% of one CPU core for a little under 2 minutes (a 4½ year old Ryzen). > After this it is down to 0.3%. All the time it is outputting > trace-redisplay messages, two I think for each timer iteration. Your Emacs is running TTY frames only. On my system, during that stage, Emacs displaying on a GUI frame consumes 50% of 1 execution unit doing this stuff. And 20% to 25% for 2 minutes is not negligible, either. So yes, we do have a problem. And we always will have a problem when redisplay goes that far in its processing when there's nothing to do, actually, and we invoke it so frequently. So please, let's try to solve this, or at least understand what's going on well enough to make a decision. > I'm a bit surprised at the moment it's taking so long to do the initial > found-type scanning, but it's not all that bad. Well, that surprise of yours is another indication that we don't have a good understanding of what's going on here. Can we please try to understand that fully? From debbugs-submit-bounces@debbugs.gnu.org Sat Dec 11 09:52:39 2021 Received: (at 52298) by debbugs.gnu.org; 11 Dec 2021 14:52:39 +0000 Received: from localhost ([127.0.0.1]:48893 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mw3jq-000773-VM for submit@debbugs.gnu.org; Sat, 11 Dec 2021 09:52:39 -0500 Received: from colin.muc.de ([193.149.48.1]:13074 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1mw3jl-00076l-Es for 52298@debbugs.gnu.org; Sat, 11 Dec 2021 09:52:37 -0500 Received: (qmail 34932 invoked by uid 3782); 11 Dec 2021 14:52:26 -0000 Received: from acm.muc.de (p2e5d532c.dip0.t-ipconnect.de [46.93.83.44]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 11 Dec 2021 15:52:26 +0100 Received: (qmail 32516 invoked by uid 1000); 11 Dec 2021 14:52:22 -0000 Date: Sat, 11 Dec 2021 14:52:22 +0000 To: Eli Zaretskii Subject: Re: bug#52298: 29.0.50; Frequent redisplay cycles induced by c-type-finder-timer-func timer in CC Mode Message-ID: References: <83sfv74hpm.fsf@gnu.org> <83wnkeuufz.fsf@gnu.org> <838rwttsxj.fsf@gnu.org> <838rwss37v.fsf@gnu.org> <83tuffr2qd.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <83tuffr2qd.fsf@gnu.org> X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 52298 Cc: acm@muc.de, 52298@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: -1.0 (-) Hello, Eli. On Sat, Dec 11, 2021 at 09:59:38 +0200, Eli Zaretskii wrote: > > Date: Fri, 10 Dec 2021 22:52:40 +0000 > > Cc: 52298@debbugs.gnu.org, acm@muc.de > > From: Alan Mackenzie > > > > I think that modify_text_properties is calling modiff_incr even when > > > > inhibit_modification_hooks is non-nil. I tried putting an `if' around > > > > that bit of the code, without any great success. > > > AFAIK, with-silent-modifications is supposed to prevent BUF_MODIFF > > > from increasing. > > I don't think it does in the modify_text_properties case. > Maybe I'm misremembering. > But let me ask you why those 2 text properties are involved in this > case, and what do they signify? c-is-sws (along with c-in-sws) marks syntactic whitespace in a buffer so that especially for long comments, passing over that WS is rapid (after the first pass has marked the properties). c-type marks certain types of identifiers and positions related to a CC Mode declaration, e.g. the start of a declarator, or the end of the previous statement. > Could we perhaps refrain from putting them on buffer text when those > functions are called from the timer? That would not be sensible. Both of them are for optimisation, and preventing them being used from the timer would involve an involved (slow) mechanism. In any case, with-silent-modifications is in force around "all" the code called from c-type-finder-timer-func - there is a c-save-buffer-state (which expands to with-silent-modifications) around all the critical code. > And why does that timer have to tick so frequently? It doesn't have to. It's just that the sooner the background scanning gets finished, the better. Though I'm beginning to have doubts about the entire mechanism, just as you have. > > > Are you sure you see that? And what kind of 'if' did you try to put > > > and where? > > In modify_text_properties, around the modiff_incr bit: > > diff --git a/src/textprop.c b/src/textprop.c > > index d7d6a66923..d91b8624ef 100644 > > --- a/src/textprop.c > > +++ b/src/textprop.c > > @@ -85,10 +85,13 @@ modify_text_properties (Lisp_Object buffer, > > Lisp_Object start, Lisp_Object end) > > prepare_to_modify_buffer_1 (b, e, NULL); > > - BUF_COMPUTE_UNCHANGED (buf, b - 1, e); > > - if (MODIFF <= SAVE_MODIFF) > > - record_first_change (); > > - modiff_incr (&MODIFF); > > + if (!inhibit_modification_hooks) > > + { > > + BUF_COMPUTE_UNCHANGED (buf, b - 1, e); > > + if (MODIFF <= SAVE_MODIFF) > > + record_first_change (); > > + modiff_incr (&MODIFF); > > + } > And modiff_incr is still being called? How's that possible, unless > you don't use with-silent-modifications when you put those 2 > properties? Or maybe modiff_incr is called from some other place as > well? I'm sure modiff_incr wasn't being called from that code with the `if' surrounding it. If might be being called from somewhere else. I don't think this manipulation of modiff_incr here is the source of the problem. > > > Once again, the problem is not that redisplay is invoked, the problem > > > is that it doesn't exit almost immediately, after detecting that > > > nothing's changed. OK, I think I see what the problem is, now. It's the middle line in .... redisplay_internal 0 071a03c8 (xdisp.c): try_window_id 2 redisplay_preserve_echo_area (8) ..... , which indicates deep processing in redisplay. (Yes, I know you've been telling me this for a while...) The question is why does the code get that deep in rather than being aborted earlier? The repeated calling of the redisplay from keyboard.c is pretty harmless. > > I'm again not entirely convinced we have a problem. When trace-redisplay > > is enabled on my machine, and xdisp.c visited, Emacs uses between 20% and > > 25% of one CPU core for a little under 2 minutes (a 4½ year old Ryzen). > > After this it is down to 0.3%. All the time it is outputting > > trace-redisplay messages, two I think for each timer iteration. > Your Emacs is running TTY frames only. On my system, during that > stage, Emacs displaying on a GUI frame consumes 50% of 1 execution > unit doing this stuff. And 20% to 25% for 2 minutes is not > negligible, either. So yes, we do have a problem. And we always will > have a problem when redisplay goes that far in its processing when > there's nothing to do, actually, and we invoke it so frequently. So > please, let's try to solve this, or at least understand what's going > on well enough to make a decision. > > I'm a bit surprised at the moment it's taking so long to do the initial > > found-type scanning, but it's not all that bad. > Well, that surprise of yours is another indication that we don't have > a good understanding of what's going on here. Can we please try to > understand that fully? Another thing. After waiting the ~2 minutes for the background scanning to complete, I had a look at which character positions had the `fontified' text property, using a simple utility I wrote some years ago: ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; (defvar regions nil) (defun get-fontified () "Display a list of regions which have the `fontified' property set. If the region has the `defer' property, it is displayed as a list. Otherwise it is displayed as a cons. Retain this list in variable `regions'." (interactive) (setq regions nil) (let* (end (beg (if (get-text-property (point-min) 'fontified) (point-min) (next-single-property-change (point-min) 'fontified)))) (while beg (setq end (or (next-single-property-change beg 'fontified) (point-max))) (push (if (eq (get-text-property beg 'fontified) 'defer) (list beg end) (cons beg end)) regions) (setq beg (if (get-text-property end 'fontified) end (next-single-property-change end 'fontified)))) (setq regions (nreverse regions))) (message "Fontified regions: %s" regions)) (global-set-key [f10] 'get-fontified) ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; Using the [f10] key (or just typing M-x get-fontified, if F10 is otherwise occupied) the following positions ended up fontified in X-Windows after that 2 minute pause: "Fontified regions: ((1 . 1740))" , That is, at the end, only the visible portion and a bit more were fontified. This suggests (though not conclusively) that no fontification happened anywhere else in the buffer. Yet another thing: I had a look at the commit where I introduced this mechanism back in October, and it wasn't any faster then. I think my figure of 18s came from timing it in the foreground, disregarding the influence of the timer mechanism. I can't remember clearly any more. -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Sat Dec 11 10:38:55 2021 Received: (at 52298) by debbugs.gnu.org; 11 Dec 2021 15:38:55 +0000 Received: from localhost ([127.0.0.1]:49892 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mw4Sd-0008SR-CA for submit@debbugs.gnu.org; Sat, 11 Dec 2021 10:38:55 -0500 Received: from eggs.gnu.org ([209.51.188.92]:39532) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mw4SY-0008SB-T1 for 52298@debbugs.gnu.org; Sat, 11 Dec 2021 10:38:53 -0500 Received: from [2001:470:142:3::e] (port=33652 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mw4ST-0006Iv-Hh; Sat, 11 Dec 2021 10:38:45 -0500 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=xedAEUfVK0KX0sEpcQAVQpeULl71lh+uyaNO2V8Jxjk=; b=EiKBEa+SMxjf c0T5am5EdS7gayITVTOOEq+47+MxxuHj8k86eXh05r2bFJgumGafpKwEv3eoaUW/0CBYlUsvxuuYO +g7q7RWrXAVKbubRDVfUm/QVhUcQgcYaJ6ZaRlUMKVTUChqGX40AyhUZa60h//Q7q2j1xmQR5Jl6i plqHCCN+2D+rMOlvtDK35OHIBXvgU+NU+8stRbSDReKK5gE+l7/sY5V3XfLakT9p6biLyUKy9zXlq 10VUcFbsi4OdXXaJQM3OaWHrURj+TGQuoUa5nWTSpf8uuSI2P6kSc0oUlJ30GCi/eDhrD7xEDm1JF tTOc2CweZ67XJuHUnGPz+w==; Received: from [87.69.77.57] (port=2731 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mw4ST-0007qZ-2b; Sat, 11 Dec 2021 10:38:45 -0500 Date: Sat, 11 Dec 2021 17:38:34 +0200 Message-Id: <83zgp7p2x1.fsf@gnu.org> From: Eli Zaretskii To: Alan Mackenzie In-Reply-To: (message from Alan Mackenzie on Sat, 11 Dec 2021 14:52:22 +0000) Subject: Re: bug#52298: 29.0.50; Frequent redisplay cycles induced by c-type-finder-timer-func timer in CC Mode References: <83sfv74hpm.fsf@gnu.org> <83wnkeuufz.fsf@gnu.org> <838rwttsxj.fsf@gnu.org> <838rwss37v.fsf@gnu.org> <83tuffr2qd.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 52298 Cc: acm@muc.de, 52298@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 (---) > Date: Sat, 11 Dec 2021 14:52:22 +0000 > Cc: 52298@debbugs.gnu.org, acm@muc.de > From: Alan Mackenzie > > c-is-sws (along with c-in-sws) marks syntactic whitespace in a buffer so > that especially for long comments, passing over that WS is rapid (after > the first pass has marked the properties). > > c-type marks certain types of identifiers and positions related to a CC > Mode declaration, e.g. the start of a declarator, or the end of the > previous statement. > > > Could we perhaps refrain from putting them on buffer text when those > > functions are called from the timer? > > That would not be sensible. Both of them are for optimisation, and > preventing them being used from the timer would involve an involved > (slow) mechanism. But we are talking about the timer whose job is to find type declarations. Does that job require these properties? > OK, I think I see what the problem is, now. It's the middle line in .... > > redisplay_internal 0 > 071a03c8 (xdisp.c): try_window_id 2 > redisplay_preserve_echo_area (8) > > ..... , which indicates deep processing in redisplay. (Yes, I know you've > been telling me this for a while...) The question is why does the code > get that deep in rather than being aborted earlier? I already established that, it's the fact that the buffer's modified tick is increasing. This then causes this test: current_matrix_up_to_date_p = (w->window_end_valid && !current_buffer->clip_changed && !current_buffer->prevent_redisplay_optimizations_p && !window_outdated (w) && !hscrolling_current_line_p (w)); to fail because window_outdated returns non-zero. That's how I knew that the buffer's modified tick is the culprit. > Another thing. After waiting the ~2 minutes for the background scanning > to complete, I had a look at which character positions had the > `fontified' text property, using a simple utility I wrote some years ago: > [...] > Using the [f10] key (or just typing M-x get-fontified, if F10 is > otherwise occupied) the following positions ended up fontified in > X-Windows after that 2 minute pause: > > "Fontified regions: ((1 . 1740))" > > , That is, at the end, only the visible portion and a bit more were > fontified. This suggests (though not conclusively) that no fontification > happened anywhere else in the buffer. So why is the timer function keep running for so long, and why does it put those two other properties on the rest of the buffer? It sounds to me like you could stop the timer once the visible portion of the buffer has been reached, because no type after that can affect fontification. You could then restart the timer when the buffer is modified, or if the window is scrolled to reveal a portion of the buffer below the current end-of-window. From debbugs-submit-bounces@debbugs.gnu.org Sat Dec 11 12:04:41 2021 Received: (at 52298) by debbugs.gnu.org; 11 Dec 2021 17:04:41 +0000 Received: from localhost ([127.0.0.1]:49935 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mw5nd-0004JW-7t for submit@debbugs.gnu.org; Sat, 11 Dec 2021 12:04:41 -0500 Received: from colin.muc.de ([193.149.48.1]:16422 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1mw5na-0004JF-4e for 52298@debbugs.gnu.org; Sat, 11 Dec 2021 12:04:40 -0500 Received: (qmail 22449 invoked by uid 3782); 11 Dec 2021 17:04:32 -0000 Received: from acm.muc.de (p2e5d532c.dip0.t-ipconnect.de [46.93.83.44]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 11 Dec 2021 18:04:31 +0100 Received: (qmail 1341 invoked by uid 1000); 11 Dec 2021 17:04:28 -0000 Date: Sat, 11 Dec 2021 17:04:28 +0000 To: Eli Zaretskii Subject: Re: bug#52298: 29.0.50; Frequent redisplay cycles induced by c-type-finder-timer-func timer in CC Mode Message-ID: References: <83wnkeuufz.fsf@gnu.org> <838rwttsxj.fsf@gnu.org> <838rwss37v.fsf@gnu.org> <83tuffr2qd.fsf@gnu.org> <83zgp7p2x1.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83zgp7p2x1.fsf@gnu.org> X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 52298 Cc: 52298@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: -1.0 (-) Hello, Eli. On Sat, Dec 11, 2021 at 17:38:34 +0200, Eli Zaretskii wrote: > > Date: Sat, 11 Dec 2021 14:52:22 +0000 > > Cc: 52298@debbugs.gnu.org, acm@muc.de > > From: Alan Mackenzie > > OK, I think I see what the problem is, now. It's the middle line in .... > > redisplay_internal 0 > > 071a03c8 (xdisp.c): try_window_id 2 > > redisplay_preserve_echo_area (8) > > ..... , which indicates deep processing in redisplay. (Yes, I know you've > > been telling me this for a while...) The question is why does the code > > get that deep in rather than being aborted earlier? > I already established that, it's the fact that the buffer's modified > tick is increasing. This then causes this test: > current_matrix_up_to_date_p > = (w->window_end_valid > && !current_buffer->clip_changed > && !current_buffer->prevent_redisplay_optimizations_p > && !window_outdated (w) > && !hscrolling_current_line_p (w)); > to fail because window_outdated returns non-zero. That's how I knew > that the buffer's modified tick is the culprit. Ah, OK. Then this bit seems clear. With that patch of mine in textprop.c, which tests inhibit_modification_hooks before modifying the tick, I don't see the "try_window_id 2" lines in the trace-redisplay output. So, I suggest I write a commit message and commit that patch. ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; Unfortunately, it makes little difference to the CPU usage of CC Mode in the few minutes after visiting xdisp.c. > > c-is-sws (along with c-in-sws) marks syntactic whitespace in a buffer so > > that especially for long comments, passing over that WS is rapid (after > > the first pass has marked the properties). > > c-type marks certain types of identifiers and positions related to a CC > > Mode declaration, e.g. the start of a declarator, or the end of the > > previous statement. > > > Could we perhaps refrain from putting them on buffer text when those > > > functions are called from the timer? > > That would not be sensible. Both of them are for optimisation, and > > preventing them being used from the timer would involve an involved > > (slow) mechanism. > But we are talking about the timer whose job is to find type > declarations. Does that job require these properties? I can't say for definite, off hand, but almost certainly yes. After the first answer of this post, does it still matter? > > Another thing. After waiting the ~2 minutes for the background scanning > > to complete, I had a look at which character positions had the > > `fontified' text property, using a simple utility I wrote some years ago: > > [...] > > Using the [f10] key (or just typing M-x get-fontified, if F10 is > > otherwise occupied) the following positions ended up fontified in > > X-Windows after that 2 minute pause: > > "Fontified regions: ((1 . 1740))" > > , That is, at the end, only the visible portion and a bit more were > > fontified. This suggests (though not conclusively) that no fontification > > happened anywhere else in the buffer. > So why is the timer function keep running for so long, and why does it > put those two other properties on the rest of the buffer? It sounds > to me like you could stop the timer once the visible portion of the > buffer has been reached, because no type after that can affect > fontification. That's sadly not true. The source code which determines an identifier is a "found type" is frequently distant from the place where the identifier needs to be fontified as a type. For, example, near the beginning of a C buffer we might have: foo (bar, baz); and somewhere else we have code defining `bar' and `baz' as types, so that the code line is in fact defining a forward declaration of an int function, and isn't a function call with two arguments. Other more usual things (which I can't think of at the moment) caused the randomness in the fontification which gave rise to that long thread earlier on in the year. > You could then restart the timer when the buffer is modified, or if the > window is scrolled to reveal a portion of the buffer below the current > end-of-window. Unfortunately not. To fontify the current window contents reliably involves having scanned the entire buffer. It may well be that this refinement is too expensive in processing power to be worthwhile. I am puzzled as to why the mechanism is only taking around 20% - 25% of a CPU core's time. It is customised to take (a little more than) 0.05s of every 0.1s. Yet it is only taking a third to a half of that amount, even less when one takes garbage collection into account. -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Sat Dec 11 13:22:09 2021 Received: (at 52298) by debbugs.gnu.org; 11 Dec 2021 18:22:09 +0000 Received: from localhost ([127.0.0.1]:49967 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mw70b-0006Es-68 for submit@debbugs.gnu.org; Sat, 11 Dec 2021 13:22:09 -0500 Received: from eggs.gnu.org ([209.51.188.92]:38366) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mw70Z-0006Ed-7x for 52298@debbugs.gnu.org; Sat, 11 Dec 2021 13:22:07 -0500 Received: from [2001:470:142:3::e] (port=36232 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mw70T-0001vj-KH; Sat, 11 Dec 2021 13:22:01 -0500 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=1T05HokpVfjtDNY5tOykpp5PQST934VROowKCtWu3jI=; b=hs2e5vSBjnYz kqEPhpFQ8njH0iKkGffG4OqJzBRTi6f4Bg0vVPvTqquqOF80bjmPiEkjQCFbekR61h42gmRHdk9V6 xXTi3lsqZ0dHiHVuSxUSjxufYD0EtTW9T69EH2RPaBlFWr4TeUv7YwWBkYgAZoGhSTUd/uiKjed+y z8CcMcvBy/NhnJjcF91Qod7ByehroPeOZfIZR8jMx6w30wOJcik/zJl9c6xO5tBftpUAWVwy8KKdw Ve6NzhskkMfvJpOSLjCXcQ43nDMRi4aSVnWmmwbOecLVO1naaruEk16VXRmxn5sTVuBmpM6nXktIF JJLBVBcbO4Fq3caaqV7P5Q==; Received: from [87.69.77.57] (port=4746 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mw70T-0008Jn-Dh; Sat, 11 Dec 2021 13:22:01 -0500 Date: Sat, 11 Dec 2021 20:21:51 +0200 Message-Id: <83v8zvovcw.fsf@gnu.org> From: Eli Zaretskii To: Alan Mackenzie In-Reply-To: (message from Alan Mackenzie on Sat, 11 Dec 2021 17:04:28 +0000) Subject: Re: bug#52298: 29.0.50; Frequent redisplay cycles induced by c-type-finder-timer-func timer in CC Mode References: <83wnkeuufz.fsf@gnu.org> <838rwttsxj.fsf@gnu.org> <838rwss37v.fsf@gnu.org> <83tuffr2qd.fsf@gnu.org> <83zgp7p2x1.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 52298 Cc: 52298@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 (---) > Date: Sat, 11 Dec 2021 17:04:28 +0000 > Cc: 52298@debbugs.gnu.org > From: Alan Mackenzie > > So, I suggest I write a commit message and commit that patch. Which patch? I'm afraid I'm missing something here. From debbugs-submit-bounces@debbugs.gnu.org Sun Dec 12 03:58:20 2021 Received: (at 52298) by debbugs.gnu.org; 12 Dec 2021 08:58:20 +0000 Received: from localhost ([127.0.0.1]:50639 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mwKgW-0005JM-8L for submit@debbugs.gnu.org; Sun, 12 Dec 2021 03:58:20 -0500 Received: from colin.muc.de ([193.149.48.1]:41920 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1mwKgT-0005J6-Ng for 52298@debbugs.gnu.org; Sun, 12 Dec 2021 03:58:18 -0500 Received: (qmail 53466 invoked by uid 3782); 12 Dec 2021 08:58:11 -0000 Received: from acm.muc.de (p2e5d5b9a.dip0.t-ipconnect.de [46.93.91.154]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 12 Dec 2021 09:58:10 +0100 Received: (qmail 4833 invoked by uid 1000); 12 Dec 2021 08:58:08 -0000 Date: Sun, 12 Dec 2021 08:58:08 +0000 To: Eli Zaretskii Subject: Re: bug#52298: 29.0.50; Frequent redisplay cycles induced by c-type-finder-timer-func timer in CC Mode Message-ID: References: <838rwttsxj.fsf@gnu.org> <838rwss37v.fsf@gnu.org> <83tuffr2qd.fsf@gnu.org> <83zgp7p2x1.fsf@gnu.org> <83v8zvovcw.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83v8zvovcw.fsf@gnu.org> X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 52298 Cc: acm@muc.de, 52298@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: -1.0 (-) Hello, Eli. On Sat, Dec 11, 2021 at 20:21:51 +0200, Eli Zaretskii wrote: > > Date: Sat, 11 Dec 2021 17:04:28 +0000 > > Cc: 52298@debbugs.gnu.org > > From: Alan Mackenzie > > So, I suggest I write a commit message and commit that patch. > Which patch? I'm afraid I'm missing something here. This one, the one that should prevent excessive incursions into the redisplay engine when a text property gets set whilst inhibit-modification-hooks is set: diff --git a/src/textprop.c b/src/textprop.c index d7d6a66923..d91b8624ef 100644 --- a/src/textprop.c +++ b/src/textprop.c @@ -85,10 +85,13 @@ modify_text_properties (Lisp_Object buffer, Lisp_Object start, Lisp_Object end) prepare_to_modify_buffer_1 (b, e, NULL); - BUF_COMPUTE_UNCHANGED (buf, b - 1, e); - if (MODIFF <= SAVE_MODIFF) - record_first_change (); - modiff_incr (&MODIFF); + if (!inhibit_modification_hooks) + { + BUF_COMPUTE_UNCHANGED (buf, b - 1, e); + if (MODIFF <= SAVE_MODIFF) + record_first_change (); + modiff_incr (&MODIFF); + } bset_point_before_scroll (current_buffer, Qnil); -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Sun Dec 12 04:16:07 2021 Received: (at 52298) by debbugs.gnu.org; 12 Dec 2021 09:16:07 +0000 Received: from localhost ([127.0.0.1]:50666 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mwKxi-0005kn-Ve for submit@debbugs.gnu.org; Sun, 12 Dec 2021 04:16:07 -0500 Received: from eggs.gnu.org ([209.51.188.92]:52636) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mwKxg-0005k4-IX for 52298@debbugs.gnu.org; Sun, 12 Dec 2021 04:16:05 -0500 Received: from [2001:470:142:3::e] (port=55024 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mwKxK-0008UW-Lj; Sun, 12 Dec 2021 04:15:59 -0500 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=vQob3UaBib1XgDDBbehBsWVQ1Rg9ElGDqzRX36coLzM=; b=D4zvtf1rYcT2 6+yPeOANzashfA5rPuSaCvl9hT2/dYggh1khtzKWJhJxNv7CCTFW6l6l+4qrCRlrNUxiDrCR9460E uKG6pUpgVapvyirNmcNplzXYajzDiPcu3UnKtz3IhMtA//HsF2sZh85NraCT/bWEAwZUbJHuZ+Ivq 63HvVbB9CvBcLwiQgGHvoDJDuTurOMWJs+MRbrR4zMEJDQDKADT76RRkk2Io8MSRSnxjL7vRkJ9nY dM+Hy7aV9izle73YvJCjJfhlFrZvOsc0wzC8v4fS+QhPYpiMmKRBSud/HifRMRcFTUGcZbWwOyCkT 408TwgzpZa0wwSQWVbXDqw==; Received: from [87.69.77.57] (port=3713 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mwKxJ-0001vX-Ig; Sun, 12 Dec 2021 04:15:41 -0500 Date: Sun, 12 Dec 2021 11:15:34 +0200 Message-Id: <837dcap4jt.fsf@gnu.org> From: Eli Zaretskii To: Alan Mackenzie In-Reply-To: (message from Alan Mackenzie on Sun, 12 Dec 2021 08:58:08 +0000) Subject: Re: bug#52298: 29.0.50; Frequent redisplay cycles induced by c-type-finder-timer-func timer in CC Mode References: <838rwttsxj.fsf@gnu.org> <838rwss37v.fsf@gnu.org> <83tuffr2qd.fsf@gnu.org> <83zgp7p2x1.fsf@gnu.org> <83v8zvovcw.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 52298 Cc: 52298@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 (---) > Date: Sun, 12 Dec 2021 08:58:08 +0000 > Cc: 52298@debbugs.gnu.org, acm@muc.de > From: Alan Mackenzie > > > > So, I suggest I write a commit message and commit that patch. > > > Which patch? I'm afraid I'm missing something here. > > This one, the one that should prevent excessive incursions into the > redisplay engine when a text property gets set whilst > inhibit-modification-hooks is set: No, this cannot be used as-is, because when face properties change, we do want redisplay to take notice, of course. I guess that's why inhibit-modification-hooks doesn't prevent incrementing the modification tick when text properties are changed in the first place: it's not feasible to know which text properties affect the display and which don't. No one expected text properties irrelevant to display to be put on buffer text with such high frequency. If you don't have any other ideas, I guess we will have to live with this. Too bad. (Sorry, but I like CC Mode less and less with every Emacs release, due to changes like this one.) From debbugs-submit-bounces@debbugs.gnu.org Sun Dec 12 14:05:56 2021 Received: (at 52298) by debbugs.gnu.org; 12 Dec 2021 19:05:56 +0000 Received: from localhost ([127.0.0.1]:53158 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mwUAW-0006od-4o for submit@debbugs.gnu.org; Sun, 12 Dec 2021 14:05:56 -0500 Received: from colin.muc.de ([193.149.48.1]:58161 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1mwUAU-0006oO-GK for 52298@debbugs.gnu.org; Sun, 12 Dec 2021 14:05:55 -0500 Received: (qmail 53639 invoked by uid 3782); 12 Dec 2021 19:05:47 -0000 Received: from acm.muc.de (p2e5d5b9a.dip0.t-ipconnect.de [46.93.91.154]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 12 Dec 2021 20:05:47 +0100 Received: (qmail 26662 invoked by uid 1000); 12 Dec 2021 19:05:45 -0000 Date: Sun, 12 Dec 2021 19:05:45 +0000 To: Eli Zaretskii Subject: Re: bug#52298: 29.0.50; Frequent redisplay cycles induced by c-type-finder-timer-func timer in CC Mode Message-ID: References: <838rwss37v.fsf@gnu.org> <83tuffr2qd.fsf@gnu.org> <83zgp7p2x1.fsf@gnu.org> <83v8zvovcw.fsf@gnu.org> <837dcap4jt.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <837dcap4jt.fsf@gnu.org> X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 52298 Cc: 52298@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: -1.0 (-) Hello, Eli. On Sun, Dec 12, 2021 at 11:15:34 +0200, Eli Zaretskii wrote: > > Date: Sun, 12 Dec 2021 08:58:08 +0000 > > Cc: 52298@debbugs.gnu.org, acm@muc.de > > From: Alan Mackenzie > > > > So, I suggest I write a commit message and commit that patch. > > > Which patch? I'm afraid I'm missing something here. > > This one, the one that should prevent excessive incursions into the > > redisplay engine when a text property gets set whilst > > inhibit-modification-hooks is set: > No, this cannot be used as-is, because when face properties change, we > do want redisplay to take notice, of course. I guess that's why > inhibit-modification-hooks doesn't prevent incrementing the > modification tick when text properties are changed in the first place: > it's not feasible to know which text properties affect the display and > which don't. No one expected text properties irrelevant to display to > be put on buffer text with such high frequency. Yes, that makes sense, thanks. Maybe I'll put a comment in there saying that. > If you don't have any other ideas, I guess we will have to live with > this. Too bad. > (Sorry, but I like CC Mode less and less with every Emacs release, due > to changes like this one.) This particular feature simply hasn't worked out well. If the background scanning were to complete in a few seconds, it wouldn't be too bad. But nearly two minutes on a modern (well, 4½ yo) machine for just one buffer, with the annoyance of the "stuttering", is not worth the gain. What we have is effectively the entire buffer getting half-fontified in the background. That's not what JIT fontification is supposed to be about. So, in the next few days sometime, I will revert most of this change. A useful and harmless piece of it (fontifying a newly found type throughout the buffer when it is encountered in "normal" jit fontification), I plan to leave in. That will get rid of that timer and all the background scanning it triggered. -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Sun Dec 12 14:21:56 2021 Received: (at 52298) by debbugs.gnu.org; 12 Dec 2021 19:21:56 +0000 Received: from localhost ([127.0.0.1]:53183 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mwUPz-0000y1-Vn for submit@debbugs.gnu.org; Sun, 12 Dec 2021 14:21:56 -0500 Received: from eggs.gnu.org ([209.51.188.92]:35432) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mwUPy-0000xo-1L for 52298@debbugs.gnu.org; Sun, 12 Dec 2021 14:21:54 -0500 Received: from [2001:470:142:3::e] (port=37978 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mwUPs-0003js-JB; Sun, 12 Dec 2021 14:21:48 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=j314M+YjepaQD3mpwMOPhOLw8QCuLz+JEvs1acT+waU=; b=TTjiFfnJMOsigeafPnoO y/5PkmIuEsZ14dZWr6Z0gZL07idIyG+xHH0MIFk58hFcdjO3GuBZh5OPk3dgFTNZmmtus5ivw9AvW oQk90Wl84WyWtKbFtEgcaANnM2MA2Cv/QNMrCK60T8AmgFlCT0CRUg+dS7vRDgOl4lVIPW0v4bLJF Cwa6VOR33Jbz0c/HBbUO9ayZdcB8GLwd+mtWJpNAVMIQN3UX51CBJT6N+BToOdPrryixm7nj9Ohpd CAoM9CMgHhCSfgqeGREbGIsQBShDFYnYcLo0WZicGuw/KmHQYKEqGo1HHx5uGvp9O114uAZsn6rxM QonhWMMpuPklvQ==; Received: from [87.69.77.57] (port=1823 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mwUPs-0007as-Cy; Sun, 12 Dec 2021 14:21:48 -0500 Date: Sun, 12 Dec 2021 21:21:40 +0200 Message-Id: <83zgp5mxx7.fsf@gnu.org> From: Eli Zaretskii To: Alan Mackenzie In-Reply-To: (message from Alan Mackenzie on Sun, 12 Dec 2021 19:05:45 +0000) Subject: Re: bug#52298: 29.0.50; Frequent redisplay cycles induced by c-type-finder-timer-func timer in CC Mode References: <838rwss37v.fsf@gnu.org> <83tuffr2qd.fsf@gnu.org> <83zgp7p2x1.fsf@gnu.org> <83v8zvovcw.fsf@gnu.org> <837dcap4jt.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 52298 Cc: 52298@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 (---) > Date: Sun, 12 Dec 2021 19:05:45 +0000 > Cc: 52298@debbugs.gnu.org > From: Alan Mackenzie > > This particular feature simply hasn't worked out well. If the > background scanning were to complete in a few seconds, it wouldn't be > too bad. But nearly two minutes on a modern (well, 4½ yo) machine for > just one buffer, with the annoyance of the "stuttering", is not worth > the gain. > > What we have is effectively the entire buffer getting half-fontified in > the background. That's not what JIT fontification is supposed to be > about. Maybe just lowering the frequency of the time would be enough. Or running it off an idle timer. E.g., I'm a happy user if jit-stealth, and it never causes me any annoying side effects. So maybe this feature could run similarly? Thanks. From debbugs-submit-bounces@debbugs.gnu.org Sun Dec 12 18:31:52 2021 Received: (at 52298) by debbugs.gnu.org; 12 Dec 2021 23:31:52 +0000 Received: from localhost ([127.0.0.1]:53425 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mwYJs-000770-Cx for submit@debbugs.gnu.org; Sun, 12 Dec 2021 18:31:52 -0500 Received: from sonic308-19.consmr.mail.ir2.yahoo.com ([77.238.178.147]:37602) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mwYJq-00076i-9L for 52298@debbugs.gnu.org; Sun, 12 Dec 2021 18:31:51 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.es; s=s2048; t=1639351903; bh=L2T9+RI1Eu3wLxg7MMPXpDsJUCB24XUdsHgQAxii5zo=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From:Subject:Reply-To; b=PEdKXEFGQM8P3EEKo0YLcN79C5UHqiwLPOHGpDAZEtK0w//9P36OUOiDX0reXs1VlltHGXaLWchp+r9IP0HfUp9QFgG+VC6dRwmux1Ak9y5be7cBUBnBQK1ss1V1/3srP85YndzOlEBlVz4hlekFV7I9afiR2C+UR5zkdRHBFfj3kv7Mcf+kmnRhgBUctd1ihxs6tGPUMPOxks1RyJ6ZDmripQ2mhRJTWubtikRfvOYdYy3/CvDEnDRhLSBaRSP7rIR8u+LWtowvZ++42YUesE0eVs8oVsHG7CKXGso7Re6lA5QJ/IHsZuskKsp2Q6WQ3fnBZYpQ9/+u7sdIR9Qxeg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1639351903; bh=jGavApk/2wrPeue1JNLxpGb8Zfeud/Cr0JRTzTWBHmq=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=n5C5LWbFYvNv7MiACHK1WWw6xRnQ/yb3tFBcEf08cWpjvt+nAhD0024zCCJt2IHoXcYQqcqmWWCm8f3aeMOlzsfSXCqqQWDFfoUmQXyUgCfCe6hSWxFvUunHmt4mzJhAtLLJS0a8IBLhKANx1G+KGnQEce9bVxem89ZLIZSL3FUeuza1R/xg36L5FQnDNmJG669oOXAhSzlIeq4rv21syTQ6MQKS399GgH+KBeyj8KGqZAu10NbX+O8IxYHI5pWoYobWizzgecGeWaEFTIIq/VFKIdKmfhxnvF7F1IZXAAX50FvPBeVl0dWXn59ns/R38sm6LgF6lXI0+S9tQkqBPQ== X-YMail-OSG: yJB1_xoVM1lvhL4bgdPh5g02k7EYAaqGvz4S3Zd4Qcsuqx.3Wjhf.bc4wqJ36gs ZUYEM_gp2U8UV5D0f.cTWINAJywOB.sSnsDF7fyi82c8kJch5eCHVQrrGXr3s.NBxU_YImhLaxPq 8JxzgRwiUaLrIjFznblm6gnr7kA82DKFTWvaq6XplCqoHaIr9BQ4ukavo6kPyW0nd9k1Gu1HuMW1 dxA_S3ljcHMD2bqqUe9l063AvN7IUrjz8mBpBjXJY3Jt_jOU8jiv8IdBbDYrc18q8jbyaIZrYQwQ P.uJiyHnJpInF6hIHCwNMVu1X41eILM6_h8sPVVgiRyB0SJbDBHYEK1q8K0txYbS8hyeVpTiVxFy Ew5e9GXHesi9rjE0HQAiv8QZEhn6Ca_XZLKN.DInwVccSdq6RLogG4g3m7AYxT8Ro.QS0S1WpP2D _Zoa_YW_z4M9OZeHYjywoVyVk7C5NtFO8wjSaQy54QvEJCksNtEOT3_ZcSyw8hGZg_MeIKnEYyFQ 9IP75M5d_llRerumKSdzhztBVcritzyCBribAICOZ3CgHmqH8EZ9tQK72rlMkrmNG79Hwmygm2Tj rCFJKkMQSTI7eoWjRL4TCqHK1npoZd.8XePGLzjrLVojW7LQp8sBMRqHDRzbGhfxh33Ez.uCV66. CvI4EZwTHWMnXfknW5wG.6R3_4kdgk4e9DKqcTytpll3XGlNeNZLpraX6nNk6fwbN2PqmEvh3a40 72TAPIAGXfMyajfJ8nuyZqof16FM8ccStD8.60CgVmUwRD3CCLowYlv0JAxIBCMaV51hVE4QhZTj 6p4zlEQYfy8IoikdH6T48c9uTZ8D7aVmD7vPonA1yb1kqe8l1v8fx0.T.WZJjdHPKNyOdyt_xXqr rB_DcG83tfo8I.Z1mCyKVvks_oCx5VWG9uZwENgACJ4vh1QtfwJYdUxUe2Z.ogRAkKM1KmB8hrEi x3eT2AhZjWN9MAqf.LQBIIm1OLNgJ02nSN.nYy8vdYvXJqH.X8fua.6nmonzSNPQZRwzijUi9f5o BRHYp2KnjhOGjtTnz6SC.taID0c6YngYTzaCROzcyW75JHxEJxJ13aRMCRELR8OlGh_yNPFG7XU8 bfN0bjDkrNRwR6yl4_d4iOQ84.S4ILGAItlhBMCHcomAjr9XZn0of9aIeVDQJh8ARXvfFVvyf6h8 KYZ0SKl8ace_gNG_HZ8.DwPlGAgBfB9rYxVPIi6WfeXqWg2ICKtBv98RLVTIe2N70DZKF4m.V5Qq Ak.tVOCy70H0L4aJz1St1HkKniG3wPTFO_9Qv.jxwMKEtMZeyJT2qr0M3iVRG2E46m1kUxzOtHUY MFZNAwrTfSFvx7WLwQ8vxSmfYvlJNgUGyz_cvWEltMP5us7aA1JbLEKoAhtCDY0grR5ljA7MUG7G MAj.BAe.PEkoPYzicOqq5g9Blr1Cx62bLhrTCE5c7Tbw9PQZTC9gaNQFa7XFfPEA9fqmNs9wTTdQ z5L5wF2ZO0GDmcxl.jD_LUa8LKRGjQkY.xN7EUBJMG8UGLRRVhs1mhqz_ky0kcsizNe0dJjafrr5 U_cxoDG5_PU2OWuopohzHF01f_tiTvTetALgmskc1SFYKqDiwZiZPMNTMDOr4ni5hi0h3CiYjdgM 29rexflE_Yu39Mlh8hPTwSQyIwIWr5Y3tt2BYyeyoqY1YjUt5jkRPqT9xrL7fwZXSxsf0LzvNlMd ryUrw9u9E4L8USFMOdQJKOLoYMidVw8Jm53m01jZXKs8Y04QN4AoIOISCCQTjP2CXprGT5hbjS9z kaolGUL_9WBfke330bz3_Y7fv7xabGNa0gNxij0PRvOhxsA_AzIDIyn1RYET5lRNnlaFg0PJcniv 4VbJluh1fZUD0d09_Ijfn04KiVPdLWbOqpr3h72Oxznj1.rmbzNa9ScWPIJD8qPo_b0W8J3hiXIH R1MlmkiOPu.T.6lYM2Fk8Fe9Fr4ra.Y8AXCLb5_8iU2qxvUfJ0C2FFNMsYsi_K1lLNZt431rx7e6 W8pN7ufm5yr3WM0YoAcORDOUZJmJxdLk6hbWkoVloEg.DH5FnUWB4.USM58HCmFGT3xKBAxslhGB Sk7VOclJur6IbjkmpZ5gWZ0Zda1oj0DKKIxb.dxTUZ1iMgh3HnsFPFnHfBXMvoRbgoZow4BJIlnV PcO66UH.WUobdk1F96N7HFM.J7NBptMKFKTV4NvXEaU2.Lhtq9tK1leXnLBJ.GrFFD5qsRbiqnbb 610nWjVEzviyvUwMJ51JZOYG.VOEblfXms9OMW1C97iplW0fg5i6EHwWmT9ROtVtvig-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.ir2.yahoo.com with HTTP; Sun, 12 Dec 2021 23:31:43 +0000 Received: by kubenode511.mail-prod1.omega.ir2.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 8f1fa5054f717d592df3618a132bacad; Sun, 12 Dec 2021 23:31:39 +0000 (UTC) From: =?utf-8?Q?Daniel_Mart=C3=ADn?= To: Alan Mackenzie Subject: Re: bug#52298: 29.0.50; Frequent redisplay cycles induced by c-type-finder-timer-func timer in CC Mode References: <838rwss37v.fsf@gnu.org> <83tuffr2qd.fsf@gnu.org> <83zgp7p2x1.fsf@gnu.org> <83v8zvovcw.fsf@gnu.org> <837dcap4jt.fsf@gnu.org> Date: Mon, 13 Dec 2021 00:31:38 +0100 In-Reply-To: (Alan Mackenzie's message of "Sun, 12 Dec 2021 19:05:45 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (darwin) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailer: WebService/1.1.19415 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Content-Length: 680 X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 52298 Cc: Eli Zaretskii , 52298@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: -0.8 (/) Alan Mackenzie writes: > > This particular feature simply hasn't worked out well. If the > background scanning were to complete in a few seconds, it wouldn't be > too bad. But nearly two minutes on a modern (well, 4=C2=BD yo) machine f= or > just one buffer, with the annoyance of the "stuttering", is not worth > the gain. If you want another data point, on my 2017 MacBook Pro visiting xdisp.c took 1:30 min of background work (using 25% of the CPU). Is it possible to make the feature optional, even for the default font-lock decoration level in CC mode? So only the people that want more accurate highlighting of types pay the cost of this background work. From debbugs-submit-bounces@debbugs.gnu.org Mon Dec 13 09:19:50 2021 Received: (at 52298) by debbugs.gnu.org; 13 Dec 2021 14:19:50 +0000 Received: from localhost ([127.0.0.1]:54471 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mwmBC-0002xa-D7 for submit@debbugs.gnu.org; Mon, 13 Dec 2021 09:19:50 -0500 Received: from colin.muc.de ([193.149.48.1]:34394 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1mwmB9-0002xL-Jl for 52298@debbugs.gnu.org; Mon, 13 Dec 2021 09:19:48 -0500 Received: (qmail 32390 invoked by uid 3782); 13 Dec 2021 14:19:41 -0000 Received: from acm.muc.de (p4fe15a61.dip0.t-ipconnect.de [79.225.90.97]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 13 Dec 2021 15:19:41 +0100 Received: (qmail 18055 invoked by uid 1000); 13 Dec 2021 14:19:40 -0000 Date: Mon, 13 Dec 2021 14:19:40 +0000 To: Eli Zaretskii Subject: Re: bug#52298: 29.0.50; Frequent redisplay cycles induced by c-type-finder-timer-func timer in CC Mode Message-ID: References: <83tuffr2qd.fsf@gnu.org> <83zgp7p2x1.fsf@gnu.org> <83v8zvovcw.fsf@gnu.org> <837dcap4jt.fsf@gnu.org> <83zgp5mxx7.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <83zgp5mxx7.fsf@gnu.org> X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 52298 Cc: 52298@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: -1.0 (-) Hello, Eli. On Sun, Dec 12, 2021 at 21:21:40 +0200, Eli Zaretskii wrote: > > Date: Sun, 12 Dec 2021 19:05:45 +0000 > > Cc: 52298@debbugs.gnu.org > > From: Alan Mackenzie > > This particular feature simply hasn't worked out well. If the > > background scanning were to complete in a few seconds, it wouldn't be > > too bad. But nearly two minutes on a modern (well, 4½ yo) machine for > > just one buffer, with the annoyance of the "stuttering", is not worth > > the gain. > > What we have is effectively the entire buffer getting half-fontified in > > the background. That's not what JIT fontification is supposed to be > > about. > Maybe just lowering the frequency of the time would be enough. Then instead of the scanning taking 2 minutes, it would take 10 or 20. And that's just for one buffer, albeit a large one. I would then, possibly, get complaints about CC Mode having to "warm up" for half an hour before it was ready for use. (Only half-serious.) > Or running it off an idle timer. E.g., I'm a happy user of > jit-stealth, and it never causes me any annoying side effects. So > maybe this feature could run similarly? I think it would be better just to use jit-stealth fontification, and not have a special stealth-like feature for CC Mode. With part of the feature left in the code (the bit that causes the buffer's entire fontification to be updated when a new found type is found), the current stealth will eventually correct any wrongly fontified found types. Sadly, there seem to be limits on how far correctness can go. Maybe when our PC cores are 10 times as powerful (if that ever happens), this feature could return. I suspect CC Mode may have been superseded by then. > Thanks. -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Mon Dec 13 09:25:32 2021 Received: (at 52298) by debbugs.gnu.org; 13 Dec 2021 14:25:32 +0000 Received: from localhost ([127.0.0.1]:54477 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mwmGi-000365-3C for submit@debbugs.gnu.org; Mon, 13 Dec 2021 09:25:32 -0500 Received: from colin.muc.de ([193.149.48.1]:34538 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1mwmGe-00035o-MN for 52298@debbugs.gnu.org; Mon, 13 Dec 2021 09:25:30 -0500 Received: (qmail 35979 invoked by uid 3782); 13 Dec 2021 14:25:22 -0000 Received: from acm.muc.de (p4fe15a61.dip0.t-ipconnect.de [79.225.90.97]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 13 Dec 2021 15:25:21 +0100 Received: (qmail 18075 invoked by uid 1000); 13 Dec 2021 14:25:20 -0000 Date: Mon, 13 Dec 2021 14:25:20 +0000 To: Daniel =?iso-8859-1?Q?Mart=EDn?= Subject: Re: bug#52298: 29.0.50; Frequent redisplay cycles induced by c-type-finder-timer-func timer in CC Mode Message-ID: References: <83tuffr2qd.fsf@gnu.org> <83zgp7p2x1.fsf@gnu.org> <83v8zvovcw.fsf@gnu.org> <837dcap4jt.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 52298 Cc: acm@muc.de, Eli Zaretskii , 52298@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: -1.0 (-) Hello, Daniel. On Mon, Dec 13, 2021 at 00:31:38 +0100, Daniel Martín wrote: > Alan Mackenzie writes: > > This particular feature simply hasn't worked out well. If the > > background scanning were to complete in a few seconds, it wouldn't > > be too bad. But nearly two minutes on a modern (well, 4½ yo) > > machine for just one buffer, with the annoyance of the "stuttering", > > is not worth the gain. > If you want another data point, on my 2017 MacBook Pro visiting xdisp.c > took 1:30 min of background work (using 25% of the CPU). Thanks, that's helpful. It confirms that the slow background fontification check is real, not just an artifact of my current set up. > Is it possible to make the feature optional, even for the default > font-lock decoration level in CC mode? So only the people that want > more accurate highlighting of types pay the cost of this background > work. It would be possible, but I don't think it would be a good idea. People generally tend to stay unaware of this sort of option (how many people know about stealth fontification, for example?), and the cost of maintaining it is fairly high. I still think the best thing to do is to rip it out. It was a worthwhile experiment, but one which didn't deliver the desired result. -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Sun Dec 19 09:38:23 2021 Received: (at 52298-done) by debbugs.gnu.org; 19 Dec 2021 14:38:24 +0000 Received: from localhost ([127.0.0.1]:45333 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1myxKR-0008C1-Nq for submit@debbugs.gnu.org; Sun, 19 Dec 2021 09:38:23 -0500 Received: from colin.muc.de ([193.149.48.1]:48978 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1myxKP-0008Bk-9q for 52298-done@debbugs.gnu.org; Sun, 19 Dec 2021 09:38:21 -0500 Received: (qmail 81694 invoked by uid 3782); 19 Dec 2021 14:38:14 -0000 Received: from acm.muc.de (p2e5d58c9.dip0.t-ipconnect.de [46.93.88.201]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 19 Dec 2021 15:38:14 +0100 Received: (qmail 16556 invoked by uid 1000); 19 Dec 2021 14:38:14 -0000 Date: Sun, 19 Dec 2021 14:38:14 +0000 To: Eli Zaretskii Subject: Re: bug#52298: 29.0.50; Frequent redisplay cycles induced by c-type-finder-timer-func timer in CC Mode Message-ID: References: <838rwss37v.fsf@gnu.org> <83tuffr2qd.fsf@gnu.org> <83zgp7p2x1.fsf@gnu.org> <83v8zvovcw.fsf@gnu.org> <837dcap4jt.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 52298-done Cc: 52298-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: -1.0 (-) Hello, Eli. On Sun, Dec 12, 2021 at 19:05:45 +0000, Alan Mackenzie wrote: > On Sun, Dec 12, 2021 at 11:15:34 +0200, Eli Zaretskii wrote: [ .... ] > > (Sorry, but I like CC Mode less and less with every Emacs release, due > > to changes like this one.) > This particular feature simply hasn't worked out well. If the > background scanning were to complete in a few seconds, it wouldn't be > too bad. But nearly two minutes on a modern (well, 4½ yo) machine for > just one buffer, with the annoyance of the "stuttering", is not worth > the gain. > What we have is effectively the entire buffer getting half-fontified in > the background. That's not what JIT fontification is supposed to be > about. > So, in the next few days sometime, I will revert most of this change. A > useful and harmless piece of it (fontifying a newly found type > throughout the buffer when it is encountered in "normal" jit > fontification), I plan to leave in. That will get rid of that timer and > all the background scanning it triggered. I've removed this feature as promised last Sunday, and I'm sure the problem with the "stuttering" is now gone. So I'm closing the bug with this post. -- Alan Mackenzie (Nuremberg, Germany). From unknown Sun Jun 22 11:30:58 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Mon, 17 Jan 2022 12:24:12 +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