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#59738: c-ts-mode is slow with large buffers. Date: Sat, 10 Dec 2022 21:34:20 +0000 Message-ID: References: <87E351E0-2EE2-434A-9609-86506D2F263D@gmail.com> <83edtb3z6t.fsf@gnu.org> <3A956C88-F81D-4DED-B020-178291D405D9@gmail.com> <83fsdp1vke.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="38287"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Yuan Fu , 59738@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Dec 10 22:35:21 2022 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 1p47VA-0009hi-H5 for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 10 Dec 2022 22:35:20 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p47Uy-0006Ga-2g; Sat, 10 Dec 2022 16:35:08 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p47Ut-0006G0-DC for bug-gnu-emacs@gnu.org; Sat, 10 Dec 2022 16:35:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1p47Ut-0006sv-4o for bug-gnu-emacs@gnu.org; Sat, 10 Dec 2022 16:35:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1p47Ut-0006PV-0i for bug-gnu-emacs@gnu.org; Sat, 10 Dec 2022 16:35:03 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 10 Dec 2022 21:35:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 59738 X-GNU-PR-Package: emacs Original-Received: via spool by 59738-submit@debbugs.gnu.org id=B59738.167070807324598 (code B ref 59738); Sat, 10 Dec 2022 21:35:02 +0000 Original-Received: (at 59738) by debbugs.gnu.org; 10 Dec 2022 21:34:33 +0000 Original-Received: from localhost ([127.0.0.1]:45182 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p47UO-0006Og-Qp for submit@debbugs.gnu.org; Sat, 10 Dec 2022 16:34:33 -0500 Original-Received: from mx3.muc.de ([193.149.48.5]:28097) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p47UK-0006OY-U1 for 59738@debbugs.gnu.org; Sat, 10 Dec 2022 16:34:31 -0500 Original-Received: (qmail 49443 invoked by uid 3782); 10 Dec 2022 22:34:22 +0100 Original-Received: from acm.muc.de (p4fe15e44.dip0.t-ipconnect.de [79.225.94.68]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 10 Dec 2022 22:34:22 +0100 Original-Received: (qmail 18074 invoked by uid 1000); 10 Dec 2022 21:34:20 -0000 Content-Disposition: inline In-Reply-To: <83fsdp1vke.fsf@gnu.org> X-Submission-Agent: TMDA/1.3.x (Ph3nix) 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-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:250560 Archived-At: Hello, Eli. On Thu, Dec 08, 2022 at 22:37:05 +0200, Eli Zaretskii wrote: > > From: Yuan Fu > > Date: Wed, 7 Dec 2022 16:40:15 -0800 > > Cc: Alan Mackenzie , > > 59738@debbugs.gnu.org > > > Right, but with a long series of #define lines there should be no > > > parse tree at all… > > Ok, I think I know why. At the beginning of the file there is this > > line > > #ifndef _dce_12_0_SH_MASK_HEADER > > So it’s parsed into a preproc_ifdef node, which contains every > > #define directive in the file as its immediate child. Now you have > > this node with a tons of immediate children. And querying this node > > in font-lock is very slow, even with a limited range. I think for the > > query result to be accurate, tree-sitter has to query the whole node > > without considering the range, then throw away matches that are not > > in the range. > > Anyway, I activated my backup backup plan, which goes down the parse > > tree to find a sufficiently small node to query. Now scrolling the > > header file is fast as other files. > Thanks, now c-ts-mode is twice as fast as c-mode with that file. > Great job! The bug which was causing it to be very slow is fixed, so I agree, excellent job! But I've measured it as being 62% faster (not twice as fast) as CC Mode. A "normal" C file (xdisp.c) is around 160% faster, i.e. a little over 2½ times as fast. These timings are indeed significantly faster. But given how slow CC Mode was held to be, is a factor 2.6 speed-up really all that we were expecting from c-ts-mode? This is the sort of speed-up one would get by replacing a 5 year old machine with a new one, or using an optimised build in place of a debug build. Was I perhaps a little unrealistic in expecting an order of magnitude speed-up? Is there still scope for optimisation in c-ts-mode? -- Alan Mackenzie (Nuremberg, Germany).