From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Yuan Fu Newsgroups: gmane.emacs.bugs Subject: bug#59738: c-ts-mode is slow with large buffers. Date: Sat, 10 Dec 2022 15:14:27 -0800 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 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17887"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , 59738@debbugs.gnu.org To: Alan Mackenzie Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Dec 11 00:15:16 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 1p493r-0004PT-T5 for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 11 Dec 2022 00:15:15 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p493g-0000Yz-5x; Sat, 10 Dec 2022 18:15:04 -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 1p493f-0000Ym-2u for bug-gnu-emacs@gnu.org; Sat, 10 Dec 2022 18:15: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 1p493e-0007dq-GT for bug-gnu-emacs@gnu.org; Sat, 10 Dec 2022 18:15:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1p493e-0001Li-Cr for bug-gnu-emacs@gnu.org; Sat, 10 Dec 2022 18:15:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Yuan Fu Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 10 Dec 2022 23:15: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.16707140805160 (code B ref 59738); Sat, 10 Dec 2022 23:15:02 +0000 Original-Received: (at 59738) by debbugs.gnu.org; 10 Dec 2022 23:14:40 +0000 Original-Received: from localhost ([127.0.0.1]:45681 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p493H-0001LA-MX for submit@debbugs.gnu.org; Sat, 10 Dec 2022 18:14:40 -0500 Original-Received: from mail-pj1-f52.google.com ([209.85.216.52]:38655) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p493E-0001L0-Pv for 59738@debbugs.gnu.org; Sat, 10 Dec 2022 18:14:37 -0500 Original-Received: by mail-pj1-f52.google.com with SMTP id z8-20020a17090abd8800b00219ed30ce47so11880601pjr.3 for <59738@debbugs.gnu.org>; Sat, 10 Dec 2022 15:14:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=dT62ac7VOeCdRDjuw4qZ1HAj3CGKXBfyhg/3ZFo8Dik=; b=XP8SbkCzG4Xs3d8Jw22pFr/FlLO860a1zmcTtx/Zpk2/NKTog2mXzCLe6q054ePp+m rk4yRUWsCrb3MI+YKVtV7f/mqcdfdVf94SRLcVGcJy8AnkXwSXXGtnfNsEzAIHPujUq2 JQtA+IMkxGsQsjb+VyIv+jr2vLGsjaTALj+fc4UjJhhI/Gmj56Xc3sWYc/NWVEOzmLJf vH32Z7PRDGq6Q9ossbf+LrZhZw95hhCpPgm9pG+T+n5mQP3Wr2e9cjCMo658Pr4EQNKn xvB+gUEjWmDINgOPrh/RqsBItDWIumkE85+7hs/XgdCLcgynQBMzhaLchWqZKD5Ex+7K mx7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=dT62ac7VOeCdRDjuw4qZ1HAj3CGKXBfyhg/3ZFo8Dik=; b=S6LYm4P7Jfkshn+8m6E1VFcCfN9qvEAr6nausB0TaFpBWQ7/O5eu4D5KCrqkTyMj5O ehP65IEjtOgFeaOZb8+OzGgbRT96/8ObWAwkRBxqc8xgGBfeIPMBvsWAtPqTkh+NCJ/i Ww9jn8o1cx7O3HVIbJYQLX1zsZxye4hVJHc7Zt9BGG4nkiBDWNc5eIa3N8Qgb+ny28QW fPnsoMdKf95pXBwjoQp0Lp2M7dkmNz+2tT0nxpzBfgrp/XJVJJXC48UR8YJu8UfWOg3h ODzVwI+cTBYuonpSxkKbOmrPIDjGJog6pWboxcKphGFB0/+L4Qc1hz6sxay+xjIp2RXB sLeg== X-Gm-Message-State: ANoB5pl8Qi6HJrccTfTEVxoTCJBe0BNQ2JXrIgAtzSRYfpZfRRfYJbe0 3bbSHcIt30RcH21GkkI7H3Lnfjbgcf0= X-Google-Smtp-Source: AA0mqf6WEfnPOjfI0sHWMHhQ19tN59oHOksyuFEeOrbURmlXfTAJRrEPj5v3UXp4PeVtJLf8uy9qpg== X-Received: by 2002:a17:902:ce82:b0:188:a230:98d0 with SMTP id f2-20020a170902ce8200b00188a23098d0mr15198690plg.36.1670714070684; Sat, 10 Dec 2022 15:14:30 -0800 (PST) Original-Received: from smtpclient.apple (cpe-172-117-161-177.socal.res.rr.com. [172.117.161.177]) by smtp.gmail.com with ESMTPSA id e7-20020a17090301c700b00189bf5dc96dsm3443345plh.230.2022.12.10.15.14.28 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 10 Dec 2022 15:14:29 -0800 (PST) In-Reply-To: X-Mailer: Apple Mail (2.3696.120.41.1.1) 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:250568 Archived-At: > On Dec 10, 2022, at 1:34 PM, Alan Mackenzie wrote: >=20 > Hello, Eli. >=20 > 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 >=20 >>>> Right, but with a long series of #define lines there should be no >>>> parse tree at all=E2=80=A6 >=20 >>> Ok, I think I know why. At the beginning of the file there is this >>> line >=20 >>> #ifndef _dce_12_0_SH_MASK_HEADER >=20 >>> So it=E2=80=99s 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.=20 >=20 >>> 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. >=20 >> Thanks, now c-ts-mode is twice as fast as c-mode with that file. >=20 >> Great job! >=20 > The bug which was causing it to be very slow is fixed, so I agree, > excellent job! >=20 > 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=C2=BD > times as fast. These timings are indeed significantly faster. >=20 > 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. >=20 > Was I perhaps a little unrealistic in expecting an order of magnitude > speed-up? Is there still scope for optimisation in c-ts-mode? AFAIK not too much room for optimization. Querying the patterns takes = like 99% of the time during fontification. Querying time (thus fontification time) increases as the buffer size = increases, even if we limit the range of the query to a fixed region = (which is what we do in tree-sitter font-lock). This is unlike c-mode, = where fontifying a region takes the same amount of time regardless of = the buffer size. Some benchmarks I did: In xdisp.c Time Task 0.0008 A single query for comments 0.008 All queries in c-ts-mode 0.00815 treesit-font-lock-fontify-region (1500 char) 0.0214 font-lock-fontify-region in c-mode (1500 char) 12.048 time-scroll in c-ts-mode 21.206 time-scroll in c-mode 5.539 time-scroll in fundamental-mode In treesit.c Time Task 0.00336 All queries in c-ts-mode 0.00391 treesit-font-lock-fontify-region (1500 char) 0.0281 font-lock-fontify-region in c-mode (1500 char) 1.958 time-scroll in c-ts-mode 1.969 time-scroll in c-mode 0.535 time-scroll in fundamental-mode Though I=E2=80=99ll note that tree-sitter would provide other benefits. = I don=E2=80=99t know how much time does c-mode spend on analyzing the = buffer content when user edits it, but I imagine tree-sitter to be = faster in that regard, too. That should help the perceived performance. = Also (unrelated to performance) tree-sitter makes it vastly easier to = write (and maintain) a major mode. Yuan=