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#45248: 28.0.50; Emacs freezes with big C functions Date: Tue, 22 Dec 2020 20:40:08 +0000 Message-ID: References: <87a6ufen1w.fsf@gmail.com> <87lfdvmjpw.fsf@gmail.com> <87pn36o1le.fsf@gmail.com> 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="22873"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 45248@debbugs.gnu.org To: Ravine Var Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Dec 22 21:41:11 2020 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 1kroT1-0005rN-6k for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 22 Dec 2020 21:41:11 +0100 Original-Received: from localhost ([::1]:56130 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kroT0-00043l-9Q for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 22 Dec 2020 15:41:10 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52914) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kroSs-00043Q-P6 for bug-gnu-emacs@gnu.org; Tue, 22 Dec 2020 15:41:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:39491) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kroSs-0003qn-Hl for bug-gnu-emacs@gnu.org; Tue, 22 Dec 2020 15:41:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kroSs-0003dl-Gb for bug-gnu-emacs@gnu.org; Tue, 22 Dec 2020 15:41: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: Tue, 22 Dec 2020 20:41:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 45248 X-GNU-PR-Package: emacs Original-Received: via spool by 45248-submit@debbugs.gnu.org id=B45248.160866961813919 (code B ref 45248); Tue, 22 Dec 2020 20:41:02 +0000 Original-Received: (at 45248) by debbugs.gnu.org; 22 Dec 2020 20:40:18 +0000 Original-Received: from localhost ([127.0.0.1]:51037 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kroS9-0003cR-S4 for submit@debbugs.gnu.org; Tue, 22 Dec 2020 15:40:18 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:63621 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1kroS7-0003c9-HK for 45248@debbugs.gnu.org; Tue, 22 Dec 2020 15:40:16 -0500 Original-Received: (qmail 46451 invoked by uid 3782); 22 Dec 2020 20:40:08 -0000 Original-Received: from acm.muc.de (p4fe15aec.dip0.t-ipconnect.de [79.225.90.236]) by localhost.muc.de (tmda-ofmipd) with ESMTP; Tue, 22 Dec 2020 21:40:08 +0100 Original-Received: (qmail 24519 invoked by uid 1000); 22 Dec 2020 20:40:08 -0000 Content-Disposition: inline In-Reply-To: <87pn36o1le.fsf@gmail.com> X-Delivery-Agent: TMDA/1.1.12 (Macallan) 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:196591 Archived-At: Hello again, Ravine. Sorry it's taken a little while to reply. I've been preoccupied with another bug in the meantime. On Sat, Dec 19, 2020 at 09:58:48 +0530, Ravine Var wrote: > Alan Mackenzie writes: > > Let's be clear about the situation: CC Mode does just too much > > processing in refontification for current hardware to be able to scroll > > smoothly through a buffer at normal auto-repeat speeds. Setting > > fast-but-imprecise-scrolling to non-nil is a handy workaround, but it > > isn't good enough to make the scrolling appear to be smooth when one > > holds down C-v. I think (and hope) this is what you mean by > > "stuttering". > Yes, that's what I meant. These are my keyboard settings: > $ xset q | grep "repeat rate" > auto repeat delay: 200 repeat rate: 30 > > The bug which I'm hoping to have fixed was that in the large struct in > > Wireshark's function proto_register_rrc, the scrolling got slower and > > slower as one got further into the struct. On my machine, 80% of the > > way through that struct, scrolling a single screen (62 lines) was taking > > between four and five seconds, which was unacceptably slow. With the > > bug fix, this scrolling takes about 75 milliseconds, regardless of the > > position in the struct. This is apart from the first screen drawing in > > the neighbourhood, which takes a little time to fill the new cache > > entry. > > Could you please confirm that you see the same uniformity in scrolling > > speed anywhere inside a large struct, and that the speed is acceptably > > close to instantaneous for a single scrolling operation. Or do you see > > something different? Thanks! > I still see the behavior that you have described. Just to be sure what you're seeing, I take it you see this: (i) Move point to a long way through the big struct in proto_register_rrc, e.g. with C-u 2 M->; (ii) Perform a single C-v, to ensure the caches are filled, and wait for redisplay to complete; (iii) Perform one or more C-v. These each take several seconds before redisplay is complete. I do not see this happening on my machine. Except that's not quite true. If I switch to M-x c++-mode in the file (e.g. by mistake), I see the above slowdown. I have a fix prepared for that, too. > With the patch, scrolling becomes slower and slower rapidly and the > screen locks up (using emacs -Q). By "scrolling becomes slower", do you mean (1) that the time for an isolated single full screen scroll becomes longer, the further you are through that struct? Or do you mean (2) that on auto-repeat of the C-v or PageDown key, the scrolling becomes slower? If you mean (1), I would ask you, yet again, to produce a profile, following steps (i), (ii), and (iii) above, doing M-x profiler-start after step (ii), then M-x profiler-report after step (iii). If you mean (2), from emacs -Q without enabling fast-but-imprecise-scrolling, then you are just seeing the normal expected, but unfortunate behaviour of Emacs: Emacs will not redisplay a screen as long as there is keyboard input unprocessed, but Emacs is spending its time fontifying the intermediate screens (which are not about to be displayed) as part of processing that input. 30 characters per second is faster than CC Mode can paint a single screen. For problem (2) I recommend, again, enabling fast-but-imprecise-scrolling. > I tested with a single C file containing just the function > proto_register_rrc(). I have been testing with this, too. :-) -- Alan Mackenzie (Nuremberg, Germany).