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: Fri, 10 Dec 2021 22:52:40 +0000 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-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="32196"; 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 Fri Dec 10 23:53:10 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 1mvolK-0008DR-4G for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 10 Dec 2021 23:53:10 +0100 Original-Received: from localhost ([::1]:36246 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mvolI-0002Is-Pv for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 10 Dec 2021 17:53:08 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:34134) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mvolC-0002I5-QB for bug-gnu-emacs@gnu.org; Fri, 10 Dec 2021 17:53:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:36627) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mvolC-0003r3-Hn for bug-gnu-emacs@gnu.org; Fri, 10 Dec 2021 17:53:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mvolC-0006Na-Am for bug-gnu-emacs@gnu.org; Fri, 10 Dec 2021 17:53:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 10 Dec 2021 22:53: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.163917677024504 (code B ref 52298); Fri, 10 Dec 2021 22:53:02 +0000 Original-Received: (at 52298) by debbugs.gnu.org; 10 Dec 2021 22:52:50 +0000 Original-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 Original-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 Original-Received: (qmail 70735 invoked by uid 3782); 10 Dec 2021 22:52:41 -0000 Original-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 Original-Received: (qmail 10381 invoked by uid 1000); 10 Dec 2021 22:52:40 -0000 Content-Disposition: inline In-Reply-To: <838rwss37v.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:222098 Archived-At: 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).