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: Thu, 9 Dec 2021 20:11:32 +0000 Message-ID: References: <83sfv74hpm.fsf@gnu.org> <83wnkeuufz.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="39067"; mail-complaints-to="usenet@ciao.gmane.io" Cc: acm@muc.de, 52298@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Dec 09 21:12:15 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 1mvPm1-0009xT-RC for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 09 Dec 2021 21:12:13 +0100 Original-Received: from localhost ([::1]:47432 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mvPm0-0004ea-3p for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 09 Dec 2021 15:12:12 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:36896) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mvPlq-0004eS-Bw for bug-gnu-emacs@gnu.org; Thu, 09 Dec 2021 15:12:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:33300) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mvPlq-00011G-3c for bug-gnu-emacs@gnu.org; Thu, 09 Dec 2021 15:12:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mvPlp-0000vy-V8 for bug-gnu-emacs@gnu.org; Thu, 09 Dec 2021 15:12: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: Thu, 09 Dec 2021 20:12:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 52298 X-GNU-PR-Package: emacs Original-Received: via spool by 52298-submit@debbugs.gnu.org id=B52298.16390807023565 (code B ref 52298); Thu, 09 Dec 2021 20:12:01 +0000 Original-Received: (at 52298) by debbugs.gnu.org; 9 Dec 2021 20:11:42 +0000 Original-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 Original-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 Original-Received: (qmail 1116 invoked by uid 3782); 9 Dec 2021 20:11:33 -0000 Original-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 Original-Received: (qmail 7766 invoked by uid 1000); 9 Dec 2021 20:11:32 -0000 Content-Disposition: inline In-Reply-To: <83wnkeuufz.fsf@gnu.org> X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de 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:222015 Archived-At: 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).