From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii 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:38:34 +0200 Message-ID: <83zgp7p2x1.fsf@gnu.org> References: <83sfv74hpm.fsf@gnu.org> <83wnkeuufz.fsf@gnu.org> <838rwttsxj.fsf@gnu.org> <838rwss37v.fsf@gnu.org> <83tuffr2qd.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="10657"; mail-complaints-to="usenet@ciao.gmane.io" Cc: acm@muc.de, 52298@debbugs.gnu.org To: Alan Mackenzie Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Dec 11 16:39:45 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 1mw4TQ-0002YU-GL for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 11 Dec 2021 16:39:45 +0100 Original-Received: from localhost ([::1]:44548 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mw4TO-0000JX-P6 for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 11 Dec 2021 10:39:42 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:40336) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mw4Sk-00084F-Rm for bug-gnu-emacs@gnu.org; Sat, 11 Dec 2021 10:39:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:38346) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mw4Sk-0006KU-J1 for bug-gnu-emacs@gnu.org; Sat, 11 Dec 2021 10:39:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mw4Sk-0008Sl-D7 for bug-gnu-emacs@gnu.org; Sat, 11 Dec 2021 10:39:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 11 Dec 2021 15:39:02 +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.163923713532519 (code B ref 52298); Sat, 11 Dec 2021 15:39:02 +0000 Original-Received: (at 52298) by debbugs.gnu.org; 11 Dec 2021 15:38:55 +0000 Original-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 Original-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 Original-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==; Original-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 In-Reply-To: (message from Alan Mackenzie on Sat, 11 Dec 2021 14:52:22 +0000) 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:222127 Archived-At: > 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.