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 18:39:46 +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> <83edt5u9gv.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="28633"; mail-complaints-to="usenet@ciao.gmane.io" Cc: acm@muc.de, 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 19:40: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 1p4RFM-0007FA-R5 for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 11 Dec 2022 19:40:20 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p4RFE-0005ZK-S2; Sun, 11 Dec 2022 13:40:15 -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 1p4RF4-0005XJ-E9 for bug-gnu-emacs@gnu.org; Sun, 11 Dec 2022 13:40: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 1p4RF4-0000I3-5I for bug-gnu-emacs@gnu.org; Sun, 11 Dec 2022 13:40:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1p4RF3-0001gx-Rj for bug-gnu-emacs@gnu.org; Sun, 11 Dec 2022 13:40: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 18:40: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.16707839966493 (code B ref 59738); Sun, 11 Dec 2022 18:40:01 +0000 Original-Received: (at 59738) by debbugs.gnu.org; 11 Dec 2022 18:39:56 +0000 Original-Received: from localhost ([127.0.0.1]:47612 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p4REx-0001gf-W1 for submit@debbugs.gnu.org; Sun, 11 Dec 2022 13:39:56 -0500 Original-Received: from mx3.muc.de ([193.149.48.5]:65059) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p4REv-0001gY-Om for 59738@debbugs.gnu.org; Sun, 11 Dec 2022 13:39:54 -0500 Original-Received: (qmail 47563 invoked by uid 3782); 11 Dec 2022 19:39:47 +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 19:39:46 +0100 Original-Received: (qmail 20048 invoked by uid 1000); 11 Dec 2022 18:39:46 -0000 Content-Disposition: inline In-Reply-To: <83edt5u9gv.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:250648 Archived-At: Hello, Eli. On Sun, Dec 11, 2022 at 19:38:24 +0200, Eli Zaretskii wrote: > > 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. I was advancing that figure merely as a measure of how slow such a build is. > > 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. I use an optimised build for running and debugging at the Lisp level. Occasionally I need C debugging, and so run in an "ordinary" debugging build (3 times as slow) on these occasions. I think I've only once or twice needed a super-slow build (with --with-enable-checking=all) for debugging. My question was to enquire as to whether you actually really need the 10x as slow build most of the time, or whether the normal 3x as slow (normal debugging) build or even an optimised build would suffice most of the time. > > > 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. It is both an unusual file (so unusual behaviour might be expected in Emacs with it) and fully legitimate (so Emacs should handle it with times for scrolling operations measured in seconds, not minutes). Up until Yuan fixed c-ts-mode, its scrolling was indeed measured in minutes. The bug was legitimate, and the fix is good. [ .... ] > > > 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. Yes. It remains to be seen if the tree-sitter grammars handle these unusual constructs effortlessly. I somehow suspect it won't be as simple as all that. Yuan has already raised a bug in the C grammar where it doesn't handle packet-rrc.c correctly. > 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. We're in violent agreement, here. ;-) [ .... ] -- Alan Mackenzie (Nuremberg, Germany).