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#25706: 26.0.50; Slow C file fontification Date: Mon, 14 Dec 2020 11:44:35 +0000 Message-ID: References: <05F2A660-A403-4B81-AE77-416A739160A7@acm.org> <878sa7h1a2.fsf@gmail.com> <878sa5twmq.fsf@gmail.com> <87ft4czjri.fsf@gmail.com> <871rfset9x.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="5675"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , Lars Ingebrigtsen , 25706@debbugs.gnu.org To: Ravine Var Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Dec 14 12:45:35 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 1komIJ-0001NA-O1 for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 14 Dec 2020 12:45:35 +0100 Original-Received: from localhost ([::1]:58864 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1komII-0002ox-Oa for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 14 Dec 2020 06:45:34 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33150) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1komHm-0002nu-8l for bug-gnu-emacs@gnu.org; Mon, 14 Dec 2020 06:45:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:39873) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1komHl-0003cR-QM; Mon, 14 Dec 2020 06:45:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1komHl-00011s-La; Mon, 14 Dec 2020 06:45:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org, bug-cc-mode@gnu.org Resent-Date: Mon, 14 Dec 2020 11:45:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25706 X-GNU-PR-Package: emacs,cc-mode X-GNU-PR-Keywords: moreinfo Original-Received: via spool by 25706-submit@debbugs.gnu.org id=B25706.16079462873920 (code B ref 25706); Mon, 14 Dec 2020 11:45:01 +0000 Original-Received: (at 25706) by debbugs.gnu.org; 14 Dec 2020 11:44:47 +0000 Original-Received: from localhost ([127.0.0.1]:51419 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1komHX-00011A-9Q for submit@debbugs.gnu.org; Mon, 14 Dec 2020 06:44:47 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:61279 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1komHU-00010w-Nm for 25706@debbugs.gnu.org; Mon, 14 Dec 2020 06:44:45 -0500 Original-Received: (qmail 28829 invoked by uid 3782); 14 Dec 2020 11:44:38 -0000 Original-Received: from acm.muc.de (p4fe15d20.dip0.t-ipconnect.de [79.225.93.32]) by localhost.muc.de (tmda-ofmipd) with ESMTP; Mon, 14 Dec 2020 12:44:37 +0100 Original-Received: (qmail 10998 invoked by uid 1000); 14 Dec 2020 11:44:35 -0000 Content-Disposition: inline In-Reply-To: <871rfset9x.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:196042 Archived-At: Hello, Ravine. On Mon, Dec 14, 2020 at 12:50:36 +0530, Ravine Var wrote: > Alan Mackenzie writes: > > Have you got the option fast-but-imprecise-scrolling set (or customized) > > to non-nil? If not, could I suggest you try it. It's effect is to stop > > Emacs fontifying every screen it scrolls over, instead only fontifying > > screens when it's got no more input commands waiting. This speeds > > things up quite a bit on a slower machine. > Turning on fast-but-imprecise-scrolling improves things by a lot. > Viewing and scrolling the osprey file is much faster/smoother and the > screen doesn't freeze. :-) > > Please put the following code into your *scratch* buffer (it's the same > > code I've posted before) and evaluate it: > > (defmacro time-it (&rest forms) > > "Time the running of a sequence of forms using `float-time'. > > Call like this: \"M-: (time-it (foo ...) (bar ...) ...)\"." > > `(let ((start (float-time))) > > ,@forms > > (- (float-time) start))) > > Then please load osprey_reg_map_macro.h freshly into a buffer, and type > > (or cut and paste) the following into M-: > > (time-it (let ((n 10)) (while (> n 0) (scroll-up) (sit-for 0) (setq n (1- n))))) > > What is the reported timing for scrolling these ten screens? > Running emacs -Q (master + 3 patches) : > With fast-but-imprecise-scrolling: 0.9250097274780273 > Without fast-but-imprecise-scrolling: 0.8903303146362305 Thanks for doing that further testing. That's 0.09 seconds per scrolling of a screen. That is surely an acceptably low delay. > I think using the fast-but-imprecise-scrolling option > is a workaround that can be used in underpowered machines > for big header files... Or even in up to date full powered machines. ;-) I have it enabled all the time, and my PC is very similar to your faster one. So, I propose that these two patches (the big one and the smaller one for all the c-forward-syntactic-ws's) are sufficient to fix the bug, and I propose closing it now. What do you say to that? I have looked at the other problem you mention (slow scrolling through the machine-generated function proto_register_rrc in the wireshark file packet-rrc.c) and have made significant progress towards implementing a cache for the CC Mode function c-looking-at-or-maybe-in-bracelist, which should eliminate the long delays. Have you raised a new bug for this problem, yet? -- Alan Mackenzie (Nuremberg, Germany).