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 21:14:03 +0200 Message-ID: <831qp5u51g.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> <83edt5u9gv.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="32534"; 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 20:15:23 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 1p4RnH-0008Ft-3L for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 11 Dec 2022 20:15:23 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p4Rmy-0003L3-HC; Sun, 11 Dec 2022 14: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 1p4Rmw-0003Kt-NT for bug-gnu-emacs@gnu.org; Sun, 11 Dec 2022 14:15: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 1p4Rmw-0002Td-Dd for bug-gnu-emacs@gnu.org; Sun, 11 Dec 2022 14:15:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1p4Rmw-000229-7g for bug-gnu-emacs@gnu.org; Sun, 11 Dec 2022 14:15: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 19: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.16707860547775 (code B ref 59738); Sun, 11 Dec 2022 19:15:02 +0000 Original-Received: (at 59738) by debbugs.gnu.org; 11 Dec 2022 19:14:14 +0000 Original-Received: from localhost ([127.0.0.1]:47756 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p4RmA-00021L-1a for submit@debbugs.gnu.org; Sun, 11 Dec 2022 14:14:14 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:36358) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p4Rm7-00021C-LA for 59738@debbugs.gnu.org; Sun, 11 Dec 2022 14:14:12 -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 1p4Rm1-0002PG-J4; Sun, 11 Dec 2022 14:14:05 -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=VgIb2eiq6nPUbl5s8KIauKxIgTlzSxRVuJJ5narmR5M=; b=TFdEBxUsNvEh t+N7Clyd28r0HZAw/OmyUmxZmout9xHUcwtA2bSU9/zF/+zJa7KmCDrJpZZerIYv3XvW7RrujrkY3 UjK1SG80Jff/wuWn9wBCCMvScH/BElIoVrqHQPFsGMB6Wj/S0TGD6vilPCC1UYxnrz2L3qR4jXSY3 4aupXulCfVOTC4YWdtWtGzAjNTpR1NMuoWHbXf5As9X0pS46ZDP2vBPJsluB5duWG57n9bFTbFxtE Xv7jruGeUY6V4wuf6ebp+amYv+ztnzE76WJ7X4Ldl7IJs1i5nR9pwJRZqRtVSQTujh9/r6J39i5xn l1DJVzE21rCZ/DMUQhweFQ==; 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 1p4Rm0-0002h7-Ro; Sun, 11 Dec 2022 14:14:05 -0500 In-Reply-To: (message from Alan Mackenzie on Sun, 11 Dec 2022 18:39:46 +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:250651 Archived-At: > Date: Sun, 11 Dec 2022 18:39:46 +0000 > Cc: casouri@gmail.com, 59738@debbugs.gnu.org, acm@muc.de > From: Alan Mackenzie > > > 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. I gave you my answer, based on many hours of debugging hard problem and on a lot of gray hair. Debugging optimized code is unreliable, at least with GCC and GDB. There are tricky bugs whose debugging requires setting up complex traps and sophisticated breakpoint conditions. It takes time to find these tricks, and even a single variable which is "optimized out" or a call to a function that cannot be stepped into due to inlining and moving code around can ruin a long and frustrating debugging session. I cannot afford wasting my time that way. That the DWARF data generated by GCC is either not expressive enough to tell the whole story, or GDB is not smart enough to interpret it, is IMNSHO the greatest disaster that happened to the GNU Project. Why The Powers That Be don't consider it a grave problem, I cannot imagine. I'm old enough to remember that with GCC 2.7.2 I used to debug optimized programs without any problems -- and it was a welcome feature that made GCC stand out compared to the other compilers back then, with which you simply couldn't debug optimized code. > > 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. If this proves to be a serious problem, eventually someone on our team will start making changes in the grammar files. It isn't rocket science, after all, given that the parsing itself is done elsewhere.