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: Fri, 18 Dec 2020 17:29:12 +0000 Message-ID: References: <87a6ufen1w.fsf@gmail.com> <87lfdvmjpw.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="26592"; 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 Fri Dec 18 18:30:24 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 1kqJaB-0006pl-S2 for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 18 Dec 2020 18:30:23 +0100 Original-Received: from localhost ([::1]:35548 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kqJaA-00085d-Gz for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 18 Dec 2020 12:30:22 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33904) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kqJZq-00085H-Qw for bug-gnu-emacs@gnu.org; Fri, 18 Dec 2020 12:30:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:56527) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kqJZq-0005r4-J4 for bug-gnu-emacs@gnu.org; Fri, 18 Dec 2020 12:30:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kqJZq-0007a3-EJ for bug-gnu-emacs@gnu.org; Fri, 18 Dec 2020 12:30: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, 18 Dec 2020 17:30: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.160831256329068 (code B ref 45248); Fri, 18 Dec 2020 17:30:02 +0000 Original-Received: (at 45248) by debbugs.gnu.org; 18 Dec 2020 17:29:23 +0000 Original-Received: from localhost ([127.0.0.1]:39840 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kqJZC-0007Ym-Kl for submit@debbugs.gnu.org; Fri, 18 Dec 2020 12:29:22 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:13299 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1kqJZA-0007YZ-CN for 45248@debbugs.gnu.org; Fri, 18 Dec 2020 12:29:21 -0500 Original-Received: (qmail 14527 invoked by uid 3782); 18 Dec 2020 17:29:13 -0000 Original-Received: from acm.muc.de (p4fe15901.dip0.t-ipconnect.de [79.225.89.1]) by localhost.muc.de (tmda-ofmipd) with ESMTP; Fri, 18 Dec 2020 18:29:13 +0100 Original-Received: (qmail 9747 invoked by uid 1000); 18 Dec 2020 17:29:12 -0000 Content-Disposition: inline In-Reply-To: <87lfdvmjpw.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:196340 Archived-At: Hello, Ravine. Thanks again for the fast testing and reply. On Fri, Dec 18, 2020 at 16:47:36 +0530, Ravine Var wrote: > Alan Mackenzie writes: > > As Eli surmised, the problem is the very large static struct in the > > function. > > The solution appears to be to cache positions within structs, so that > > the function searching back over brace lists needn't do so repeatedly in > > the same piece of buffer. > > I'm hoping that the following patch which implements this cache will > > solve the problem. Would you please apply it to your copy of the master > > branch, byte compile it, and try it out on various CC Mode buffers. > > Then please let me know how well it has fixed the bug. Thanks! > The patch didn't apply cleanly on master, but it still went through. Sorry, I should have asked you to do $ cd lisp/progmodes first. But I'm glad you got it applied anyway. > progmodes $ patch -p1 < ~/Downloads/patches/bug_45248_message_11.mbox [ .... ] > Testing with the large structure copied into a file showed > some initial improvement, but the screen still locked up > once scrolling reached 15% or so. > Enabling fast-but-imprecise-scrolling allowed scrolling > to happen, but there was lots of stuttering. > Profile report with emacs -Q on a Ryzen-based machine > (no fast-but-imprecise-scrolling): > https://gist.github.com/ravine-var/0116c20477dce725b02543a85e91cbab Thanks for the profile. Noticeable in it is that c-looking-at-or-maybe-in-bracelist isn't taking up masses of runtime any more. The profile is virtually identical to one I generated myself (on my own Ryzen machine). 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". 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! Maybe we can close this bug relatively soon. -- Alan Mackenzie (Nuremberg, Germany).