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

[Alan Mackenzie <acm@muc.de>]

Hello, Yuan.

On Sat, Dec 10, 2022 at 15:14:27 -0800, Yuan Fu wrote:

> > On Dec 10, 2022, at 1:34 PM, Alan Mackenzie <acm@muc.de> wrote:

[ .... ]

> > 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.  These timings are indeed significantly
> > faster.

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

> > Was I perhaps a little unrealistic in expecting an order of magnitude
> > speed-up?  Is there still scope for optimisation in c-ts-mode?

> AFAIK not too much room for optimization. Querying the patterns takes
> like 99% of the time during fontification.  Querying time (thus
> fontification time) increases as the buffer size increases, even if we
> limit the range of the query to a fixed region (which is what we do in
> tree-sitter font-lock).

This seems similar to c-mode, where a syntactically coherent region is
determined each time fontification is done.

> This is unlike c-mode, where fontifying a region takes the same amount
> of time regardless of the buffer size.

OK, thanks for the explanation.

> Some benchmarks I did:

> In xdisp.c

> Time        Task
> 0.0008      A single query for comments
> 0.008       All queries in c-ts-mode
> 0.00815     treesit-font-lock-fontify-region (1500 char)
> 0.0214      font-lock-fontify-region in c-mode (1500 char)
> 12.048      time-scroll in c-ts-mode
> 21.206      time-scroll in c-mode
> 5.539       time-scroll in fundamental-mode

> In treesit.c

> Time        Task
> 0.00336     All queries in c-ts-mode
> 0.00391     treesit-font-lock-fontify-region (1500 char)
> 0.0281      font-lock-fontify-region in c-mode (1500 char)
> 1.958       time-scroll in c-ts-mode
> 1.969       time-scroll in c-mode
> 0.535       time-scroll in fundamental-mode

Those look the same as timings I've done.

> Though I’ll note that tree-sitter would provide other benefits. I don’t
> know how much time does c-mode spend on analyzing the buffer content
> when user edits it, ....

It's quite a lot.  Occasionally, it's enough to make the response appear
a little sluggish.  This analysis, time-wise, is less critical than the
time taken for font locking, though.

> .... but I imagine tree-sitter to be faster in that regard, too. That
> should help the perceived performance. Also (unrelated to performance)
> tree-sitter makes it vastly easier to write (and maintain) a major
> mode.

Yes indeed!  We have the advantage that a core part of the functionality
is taken care of by an external party.  But we also have the disadvantage
that a core part of the functionality is taken care of by an external
party.

> Yuan

-- 
Alan Mackenzie (Nuremberg, Germany).