From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#59738: c-ts-mode is slow with large buffers. Date: Sun, 11 Dec 2022 19:38:24 +0200 Message-ID: <83edt5u9gv.fsf@gnu.org> 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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17482"; mail-complaints-to="usenet@ciao.gmane.io" Cc: casouri@gmail.com, 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 18:39:25 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 1p4QIP-0004Lc-Lr for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 11 Dec 2022 18:39:25 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p4QI8-0005H0-VV; Sun, 11 Dec 2022 12:39:09 -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 1p4QI2-0005Gj-Mg for bug-gnu-emacs@gnu.org; Sun, 11 Dec 2022 12:39: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 1p4QI2-0003VO-5o for bug-gnu-emacs@gnu.org; Sun, 11 Dec 2022 12:39:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1p4QI2-0000wY-1N for bug-gnu-emacs@gnu.org; Sun, 11 Dec 2022 12:39:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 11 Dec 2022 17:39: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.16707803143619 (code B ref 59738); Sun, 11 Dec 2022 17:39:01 +0000 Original-Received: (at 59738) by debbugs.gnu.org; 11 Dec 2022 17:38:34 +0000 Original-Received: from localhost ([127.0.0.1]:47269 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p4QHZ-0000wJ-Ig for submit@debbugs.gnu.org; Sun, 11 Dec 2022 12:38:34 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:34516) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p4QHX-0000wD-Cq for 59738@debbugs.gnu.org; Sun, 11 Dec 2022 12:38:31 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p4QHR-0003TA-Iq; Sun, 11 Dec 2022 12:38:25 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=HCSC/vXt3mOA11OsKCFdD44P02MSkX7SbxC1ivMrWik=; b=Pvnib9T9Lrz+ akBrHlMZqvA3+teRPQ+Zn5V0TQM9e2mrWuJc0Xyk3s1tnu0N1kSBGH5E+KVvcYgWwzu5brx4gngbH M9J8Nky7jJvnXsqZi66VW3sLriLjlMgy2uaQEGgr8sm8T0gJlDCP+zODuwf7QShWfYKPnOJTV4QnO iLGurkAGbKR22YWugKDevMqtFzk65I+yVYKq9hPKJaI+qN7J8uf4Ppwwa/H5/3ZH1cXAAsG4Ngy7Y m1RYJ2uDDsHGx6ZXZ9BJJ67F7rH2VDibkCaHAR4+2tRgyDXja8ldsGkrZEzmIPkLv0UqiJl+CN39z gkE49baaXr7zrZdMv2PAhA==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p4QHR-00058H-2l; Sun, 11 Dec 2022 12:38:25 -0500 In-Reply-To: (message from Alan Mackenzie on Sun, 11 Dec 2022 17:13:49 +0000) 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:250634 Archived-At: > Date: Sun, 11 Dec 2022 17:13:49 +0000 > Cc: casouri@gmail.com, 59738@debbugs.gnu.org > From: Alan Mackenzie > > > 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. The time it takes to build the Org manual doesn't bother me, since it is rarely redone, and is not part of my maintenance job. Also, in my builds I get to producing the Org manual when the Lisp files are already byte-compiled, so it takes much less than 15 min. And finally, I almost never bootstrap. > Do you really need to run in such a build all the time? It is impossible to debug Emacs efficiently on the C level using the optimized build. So yes, I'm using unoptimized builds quite a lot. > > 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. If it is an unusual file, why did you report the slow scrolling through it as a bug? We need to be consistent: either that file is legitimate and Emacs should work reasonably fast with it, or it isn't. > If I remember rightly, speed was one of the main reasons given for > introducing tree-sitter, though I may well be wrong here. Not from my POV, no. It's an important factor, but not the main reason. > > 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. I disagree. Both C and C++ are still evolving, and their syntax and semantics don't become simpler. People post bug reports against CC Mode which involve some tricky syntactical constructs all the time. Our current font-lock is just a huge collection of ad-hocery, and there's a limit to what we can do with ad-hoc code. Personally, I think this is an evolutionary dead end. It was acceptable years ago, when the incremental parsing technology was not developed enough and/or not accessible easily enough. > > 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 A small part of it. > > 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 ;-). That too.