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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sat, 10 Dec 2022 21:34:20 +0000
> Cc: Yuan Fu <casouri@gmail.com>, 59738@debbugs.gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > 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.  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.

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.

> 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.  Even when
aided by syntax-ppss, they only catch some part of the syntax, and
none of the semantics.  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.