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 17:13:49 +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> <83r0x6v3pa.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13755"; mail-complaints-to="usenet@ciao.gmane.io" Cc: casouri@gmail.com, 59738@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Dec 11 18:14: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 1p4Pu7-0003OP-Rc for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 11 Dec 2022 18:14:19 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p4Pts-0001r5-9S; Sun, 11 Dec 2022 12:14: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 1p4Ptq-0001qi-Kl for bug-gnu-emacs@gnu.org; Sun, 11 Dec 2022 12:14: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 1p4Ptq-000514-D7 for bug-gnu-emacs@gnu.org; Sun, 11 Dec 2022 12:14:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1p4Ptq-0006mK-7G for bug-gnu-emacs@gnu.org; Sun, 11 Dec 2022 12:14:02 -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 17:14: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.167077883826043 (code B ref 59738); Sun, 11 Dec 2022 17:14:02 +0000 Original-Received: (at 59738) by debbugs.gnu.org; 11 Dec 2022 17:13:58 +0000 Original-Received: from localhost ([127.0.0.1]:47133 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p4Ptm-0006lz-52 for submit@debbugs.gnu.org; Sun, 11 Dec 2022 12:13:58 -0500 Original-Received: from mx3.muc.de ([193.149.48.5]:62487) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p4Ptk-0006lq-8S for 59738@debbugs.gnu.org; Sun, 11 Dec 2022 12:13:57 -0500 Original-Received: (qmail 52733 invoked by uid 3782); 11 Dec 2022 18:13:49 +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 18:13:49 +0100 Original-Received: (qmail 19635 invoked by uid 1000); 11 Dec 2022 17:13:49 -0000 Content-Disposition: inline In-Reply-To: <83r0x6v3pa.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:250627 Archived-At: Hello, Eli. On Sun, Dec 11, 2022 at 08:45:21 +0200, Eli Zaretskii wrote: > > Date: Sat, 10 Dec 2022 21:34:20 +0000 > > Cc: Yuan Fu , 59738@debbugs.gnu.org > > From: Alan Mackenzie > > > 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. > You do all your measurements in an optimized build of Emacs. I did > mine in an unoptimized build, something that I need to use all the > time, even though my production sessions run optimized builds. In an > unoptimized build CC Mode is extremely slow. I've built an emacs-29 with CFLAGS='-O0 -g3', --with-native-compilation, and --with-enable-checking=all. Just about anything is slow in such a build. For example, converting the org mode manual from .org to .texi took ~15 minutes in the bootstrap. I think this configuration is close to your unoptimized build. Do you really need to run in such a build all the time? We're talking about an order of magnitude slow-down from an optimized build. Surely only a tiny portion of bugs actually need this level of pessimisation. Even a "normal" debugging build (without the --with-enable-checking) is going to be a factor of ~3 faster, and surely would be suitable for nearly all debugging. > For example, just visiting dce_12_0_sh_mask.h file takes a whopping 67 > sec, and M-> immediately after the file is displayed takes another 25 > sec. With c-ts-mode, these numbers are, respectively, 1.8 sec and 2 > sec. Yes. I saw pretty much the same in my pessimised build. In a normal build, these operation are ~10 times as fast. Also we're all agreed dce_12_0_sh_mask.h is an unusual file, both in its content and its size. > IOW, scrolling through the whole humongous file measures some aspect > of the redisplay (actually, JIT font-lock) performance, but that is > not all that matters when one has to edit a file; the above two > situations are also important use cases. > However, talking only about speed is looking at this from an incorrect > aspect, see below. If I remember rightly, speed was one of the main reasons given for introducing tree-sitter, though I may well be wrong here. > > 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. > Speed is not the main reason why we want to have font-lock and > indentation based on a parser library. The main reason is > _correctness_ and _accuracy_. A regexp-based fontification and > indentation engines will never be able to match parser-based engines, > because they doesn't really understand the source code. Given the current CC Mode, any increase in correctness is going to be marginal, if apparent at all. > Even when aided by syntax-ppss, they only catch some part of the > syntax, and none of the semantics. c-forward-decl-or-cast-1 and friends do analyze semantics; the level of analysis is part of the reason why CC Mode's fontification isn't fast. > The hope is that using a parser will allow us to provide much more > accurate implementations. Whether and how much this hope will > materialize is yet to be seen, but looking just at the speedup is > definitely not TRT for assessing the success of this development in > Emacs. I see the advantage of the new tree sitter modes more in a reduction of maintenance burden (though few other people will see this with respect to CC Mode ;-). -- Alan Mackenzie (Nuremberg, Germany).