bug#59738: c-ts-mode is slow with large buffers.

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sun, 11 Dec 2022 18:39:46 +0000
> Cc: casouri@gmail.com, 59738@debbugs.gnu.org, acm@muc.de
> From: Alan Mackenzie <acm@muc.de>
> 
> > 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.