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: Sun, 11 Dec 2022 13:22:31 +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="33742"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , 59738@debbugs.gnu.org To: Yuan Fu Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Dec 11 14:23: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 1p4MIV-0008aZ-R5 for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 11 Dec 2022 14:23:15 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p4MIJ-00084S-SQ; Sun, 11 Dec 2022 08:23:03 -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 1p4MII-00084A-MS for bug-gnu-emacs@gnu.org; Sun, 11 Dec 2022 08:23:02 -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 1p4MII-0007mE-ER for bug-gnu-emacs@gnu.org; Sun, 11 Dec 2022 08:23:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1p4MIH-0004OW-Vq for bug-gnu-emacs@gnu.org; Sun, 11 Dec 2022 08:23:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 11 Dec 2022 13:23:01 +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.167076496116871 (code B ref 59738); Sun, 11 Dec 2022 13:23:01 +0000 Original-Received: (at 59738) by debbugs.gnu.org; 11 Dec 2022 13:22:41 +0000 Original-Received: from localhost ([127.0.0.1]:46416 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p4MHw-0004O3-DJ for submit@debbugs.gnu.org; Sun, 11 Dec 2022 08:22:40 -0500 Original-Received: from mx3.muc.de ([193.149.48.5]:55745) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p4MHu-0004Nx-DO for 59738@debbugs.gnu.org; Sun, 11 Dec 2022 08:22:39 -0500 Original-Received: (qmail 46290 invoked by uid 3782); 11 Dec 2022 14:22:32 +0100 Original-Received: from acm.muc.de (p4fe15c11.dip0.t-ipconnect.de [79.225.92.17]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 11 Dec 2022 14:22:32 +0100 Original-Received: (qmail 6324 invoked by uid 1000); 11 Dec 2022 13:22:31 -0000 Content-Disposition: inline In-Reply-To: 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:250605 Archived-At: Hello, Yuan. On Sat, Dec 10, 2022 at 15:14:27 -0800, Yuan Fu wrote: > > On Dec 10, 2022, at 1:34 PM, Alan Mackenzie wrote: [ .... ] > > 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? > 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 seems similar to c-mode, where a syntactically coherent region is determined each time fontification is done. > This is unlike c-mode, where fontifying a region takes the same amount > of time regardless of the buffer size. OK, thanks for the explanation. > 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 Those look the same as timings I've done. > Though I’ll note that tree-sitter would provide other benefits. I don’t > know how much time does c-mode spend on analyzing the buffer content > when user edits it, .... It's quite a lot. Occasionally, it's enough to make the response appear a little sluggish. This analysis, time-wise, is less critical than the time taken for font locking, though. > .... 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. Yes indeed! We have the advantage that a core part of the functionality is taken care of by an external party. But we also have the disadvantage that a core part of the functionality is taken care of by an external party. > Yuan -- Alan Mackenzie (Nuremberg, Germany).