From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.bugs Subject: bug#52298: 29.0.50; Frequent redisplay cycles induced by c-type-finder-timer-func timer in CC Mode Date: Wed, 8 Dec 2021 20:15:46 +0000 Message-ID: References: <83sfv74hpm.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="902"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 52298@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Dec 08 21:17:38 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mv3Ni-000AcV-P1 for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 08 Dec 2021 21:17:38 +0100 Original-Received: from localhost ([::1]:37500 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mv3Nh-0000nn-Ge for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 08 Dec 2021 15:17:37 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:50626) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mv3N8-0000mS-4F for bug-gnu-emacs@gnu.org; Wed, 08 Dec 2021 15:17:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:58201) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mv3N7-0004Mr-T5 for bug-gnu-emacs@gnu.org; Wed, 08 Dec 2021 15:17:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mv3N7-0005WQ-Oq for bug-gnu-emacs@gnu.org; Wed, 08 Dec 2021 15:17:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 08 Dec 2021 20:17:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 52298 X-GNU-PR-Package: emacs X-Debbugs-Original-Cc: bug-gnu-emacs@gnu.org Original-Received: via spool by submit@debbugs.gnu.org id=B.163899456721161 (code B ref -1); Wed, 08 Dec 2021 20:17:01 +0000 Original-Received: (at submit) by debbugs.gnu.org; 8 Dec 2021 20:16:07 +0000 Original-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 Original-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 Original-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 Original-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 Original-Received: (qmail 29853 invoked by uid 3782); 8 Dec 2021 20:15:46 -0000 Original-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 Original-Received: (qmail 1201 invoked by uid 1000); 8 Dec 2021 20:15:46 -0000 Content-Disposition: inline In-Reply-To: <83sfv74hpm.fsf@gnu.org> X-Submission-Agent: TMDA/1.3.x (Ph3nix) 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-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:221948 Archived-At: 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).