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

[Alan Mackenzie <acm@muc.de>]

Hello, Eli.

On Sun, Dec 11, 2022 at 08:45:21 +0200, Eli Zaretskii wrote:
> > 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.

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.  I think this configuration is close
to your unoptimized build.

Do you really need to run in such a build all the time?  We're talking
about an order of magnitude slow-down from an optimized build.  Surely
only a tiny portion of bugs actually need this level of pessimisation.
Even a "normal" debugging build (without the --with-enable-checking) is
going to be a factor of ~3 faster, and surely would be suitable for
nearly all debugging.

> 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.

> 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.

If I remember rightly, speed was one of the main reasons given for
introducing tree-sitter, though I may well be wrong here.

> > 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.

Given the current CC Mode, any increase in correctness is going to be
marginal, if apparent at all.

> 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; the level of
analysis is part of the reason why CC Mode's fontification isn't fast.

> 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 ;-).

-- 
Alan Mackenzie (Nuremberg, Germany).