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: Wed, 9 Dec 2020 18:46:55 +0000 Message-ID: References: <53CC4F6E-716E-4D4B-8903-F32CCB676163@acm.org> <05F2A660-A403-4B81-AE77-416A739160A7@acm.org> <878sa7h1a2.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="4477"; 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 Wed Dec 09 21:00:30 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 1kn5dW-000162-Lx for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 09 Dec 2020 21:00:30 +0100 Original-Received: from localhost ([::1]:54688 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kn5dV-00013L-Kr for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 09 Dec 2020 15:00:29 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33770) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kn4VO-0003n2-Au for bug-gnu-emacs@gnu.org; Wed, 09 Dec 2020 13:48:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:52776) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kn4VN-0003n2-U1; Wed, 09 Dec 2020 13:48:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kn4VN-0003NS-Sw; Wed, 09 Dec 2020 13:48: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: Wed, 09 Dec 2020 18:48: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.160753963311513 (code B ref 25706); Wed, 09 Dec 2020 18:48:01 +0000 Original-Received: (at 25706) by debbugs.gnu.org; 9 Dec 2020 18:47:13 +0000 Original-Received: from localhost ([127.0.0.1]:36089 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kn4Ua-0002zE-BL for submit@debbugs.gnu.org; Wed, 09 Dec 2020 13:47:12 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:39009 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1kn4UU-0002q1-9w for 25706@debbugs.gnu.org; Wed, 09 Dec 2020 13:47:10 -0500 Original-Received: (qmail 63538 invoked by uid 3782); 9 Dec 2020 18:46:59 -0000 Original-Received: from acm.muc.de (p4fe15dc2.dip0.t-ipconnect.de [79.225.93.194]) by localhost.muc.de (tmda-ofmipd) with ESMTP; Wed, 09 Dec 2020 19:46:58 +0100 Original-Received: (qmail 11793 invoked by uid 1000); 9 Dec 2020 18:46:55 -0000 Content-Disposition: inline In-Reply-To: <878sa7h1a2.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:195571 Archived-At: Hello, Ravine. Thanks for doing all this testing! On Wed, Dec 09, 2020 at 13:01:31 +0530, Ravine Var wrote: > Alan Mackenzie writes: > > Anyhow, please try out the (?)final version of my patch before I commit > > it and close the bug. It should apply cleanly to the master branch. I > > might well split it into three changes, two small, one large, since > > there are, in a sense three distinct fixes there. > I tested this patch, along with Mattias' patch posted earlier, on two > machines. > On a reasonably fast machine (AMD Ryzen 3 3200G with 16 GB RAM), there > is a marked improvement in visiting and scrolling the header files > in the linux kernel tree. The complete lockups that happened earlier > did not happen. That is close to the spec of my machine, and I find that these large .h files (without braces), with the patch, now work fast enough for me. > I also tested the patches on a Chromebook (Intel Celeron N2840 with 4GB > RAM), which is similar to the machine in the original report. > Unfortunately, the behavior was still bad, with lockups and freezing. > I tried both c-mode and c++-mode with font-lock-maximum-decoration set > to 2. Thank you indeed for taking the trouble to test the patch on the lesser machine. I do not have access to such a machine. I am assuming that before this patch, such a large file like osprey_reg....h would have been completely unworkable on the machine. It sounds as though it still is. However, have you noticed any improvement at all in performance? Could I ask you please to do one more thing, and that is to take a profile on this machine where it is giving trouble. From a freshly loaded buffer, move forward (if necessary) to a troublesome spot. N.B. C-u 1 M-> moves to 10% away from the end of the buffer, C-u 2 M-> 20%, and so on. Then start the profiler and do what is causing sluggish performance. Then have a look at the final profiler output, and expand it sensibly so that the troublesome function can be found. (Optional paragraph.) How to use the profiler: Do M-x profiler-start RET, and accept the default mode with another RET. Perform the stuff to be profiled. Do M-x profiler-report, which gives three or four lines of output, each with a number and a percentage. Move point to a line with a large percentage and type RET to expand it. You can repeat this to expand further. Please expand the lines down to where the percentages remaining are around 5% or 6%. There will be quite a lot of lines near the start showing the same large percentage. Then could you please post that output here, so as to give me some idea of where the poor performance is coming from. Thanks! -- Alan Mackenzie (Nuremberg, Germany).