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 09:59:38 +0200 Message-ID: <83tuffr2qd.fsf@gnu.org> 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="19984"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 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 09:02:16 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 1mvxKh-0004zM-PP for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 11 Dec 2021 09:02:15 +0100 Original-Received: from localhost ([::1]:38244 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mvxKf-0006Vy-C1 for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 11 Dec 2021 03:02:13 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:60328) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mvxIa-0005OT-EW for bug-gnu-emacs@gnu.org; Sat, 11 Dec 2021 03:00:05 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:36896) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mvxIY-000355-RA for bug-gnu-emacs@gnu.org; Sat, 11 Dec 2021 03:00:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mvxIY-0003GV-IH for bug-gnu-emacs@gnu.org; Sat, 11 Dec 2021 03:00: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 08:00: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.163920959912518 (code B ref 52298); Sat, 11 Dec 2021 08:00:02 +0000 Original-Received: (at 52298) by debbugs.gnu.org; 11 Dec 2021 07:59:59 +0000 Original-Received: from localhost ([127.0.0.1]:48442 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mvxIU-0003Fq-Rs for submit@debbugs.gnu.org; Sat, 11 Dec 2021 02:59:59 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:59514) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mvxIS-0003Fd-G4 for 52298@debbugs.gnu.org; Sat, 11 Dec 2021 02:59:57 -0500 Original-Received: from [2001:470:142:3::e] (port=49034 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 1mvxIL-00031x-VL; Sat, 11 Dec 2021 02:59:49 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=5lGg52AFj3MKDNmWHutFKd+nEuDCVHccTdYbhB4sHBk=; b=a4JTH+Kkkc8cz2+wHN9p BR02eUyDTjSwa5IToEjXcXdCVOw3Vdak/G8VkQ1PZtbHeZfX0Ru+4/dy3Wav8lQCKxr5tiou+04Sm yHk+Y6yHzV7+4yMbcAU5hM78H+0VJ2ookM5P6lXYXMfkjWVaOryeNcD59kHjAfeJHxIR6XhiS5Jf0 x6mDaA2dvXijzyFbKx2aZjbt3g18REWmigKTplNEZIrkU4JLqSERIozK6eotvlHro5NMqfu2j+Uou FW9P1Y/WOMSUUTHZTBhZapIAZwcYKWKhq/ECTGvFN+6AzT/MewlLTlLXkKcdzI+udy/RTPVikS3cp az77ZZQAz9QtAQ==; Original-Received: from [87.69.77.57] (port=1213 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 1mvxIL-00080y-PW; Sat, 11 Dec 2021 02:59:50 -0500 In-Reply-To: (message from Alan Mackenzie on Fri, 10 Dec 2021 22:52:40 +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:222109 Archived-At: > Date: Fri, 10 Dec 2021 22:52:40 +0000 > Cc: 52298@debbugs.gnu.org, acm@muc.de > From: Alan Mackenzie > > > > 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. Maybe I'm misremembering. But let me ask you why those 2 text properties are involved in this case, and what do they signify? Could we perhaps refrain from putting them on buffer text when those functions are called from the timer? And why does that timer have to tick so frequently? > > 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); > + } And modiff_incr is still being called? How's that possible, unless you don't use with-silent-modifications when you put those 2 properties? Or maybe modiff_incr is called from some other place as well? > > 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. Your Emacs is running TTY frames only. On my system, during that stage, Emacs displaying on a GUI frame consumes 50% of 1 execution unit doing this stuff. And 20% to 25% for 2 minutes is not negligible, either. So yes, we do have a problem. And we always will have a problem when redisplay goes that far in its processing when there's nothing to do, actually, and we invoke it so frequently. So please, let's try to solve this, or at least understand what's going on well enough to make a decision. > 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. Well, that surprise of yours is another indication that we don't have a good understanding of what's going on here. Can we please try to understand that fully?