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: Sat, 11 Dec 2021 17:04:28 +0000 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 Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5800"; 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 Sat Dec 11 18:05:46 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 1mw5of-0001K0-KZ for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 11 Dec 2021 18:05:45 +0100 Original-Received: from localhost ([::1]:45430 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mw5oe-0007cZ-7e for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 11 Dec 2021 12:05:44 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:52706) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mw5nz-00078u-Vx for bug-gnu-emacs@gnu.org; Sat, 11 Dec 2021 12:05:04 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:38389) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mw5ny-0004jI-5c for bug-gnu-emacs@gnu.org; Sat, 11 Dec 2021 12:05:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mw5nx-0004KA-RP for bug-gnu-emacs@gnu.org; Sat, 11 Dec 2021 12:05: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: Sat, 11 Dec 2021 17:05: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.163924228116591 (code B ref 52298); Sat, 11 Dec 2021 17:05:01 +0000 Original-Received: (at 52298) by debbugs.gnu.org; 11 Dec 2021 17:04:41 +0000 Original-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 Original-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 Original-Received: (qmail 22449 invoked by uid 3782); 11 Dec 2021 17:04:32 -0000 Original-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 Original-Received: (qmail 1341 invoked by uid 1000); 11 Dec 2021 17:04:28 -0000 Content-Disposition: inline In-Reply-To: <83zgp7p2x1.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:222131 Archived-At: 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).