bug#59415: 29.0.50; [feature/tree-sitter] c-ts-mode fails to fontify a portion of a large C file

[Eli Zaretskii]

> From: Theodor Thornhill <theo@thornhill.no>
> Cc: Eli Zaretskii <eliz@gnu.org>, Bug Report Emacs <bug-gnu-emacs@gnu.org>
> Date: Sun, 20 Nov 2022 22:56:12 +0100
> 
> > I tried the "top-level node” approach, and it didn’t help in
> > package-rrc.c: the top-level node (a function definition) is still too
> > large (spans 7680306-9936062). Since the case I described in the
> > comment against using treesit-node-on is the exception rather than the
> > norm, maybe we can go the other way around: use treesit-node-on first,
> > and if the node seems too small (by some heuristic), enlarge it to
> > some degree.
> >
> 
> Makes sense!
> 
> BTW, should the chunk-size of jit-lock be up for discussion again?  I
> ran the benchmarks from this thread [0] on this file, and it seems like
> increasing the chunk-size from 1500 to 4500 by 500 increments makes it
> average from 2 seconds to 1.65.
> 
> The density of that file absolutely is a concern performance-wise.

FWIW, if the root cause is the humongous data structure, I'm not too
worried, because such cases are extremely rare.  If some clever idea arises
that could improve things without endangering more practical use cases, then
fine; otherwise, I'm okay with the slightly slower performance in these
extreme cases -- after all, the interactive responsiveness is not that bad.

But I still don't understand why fontifications stopped _completely_
starting at that line.  That is, if the entire strict is in error, why most
of it is fontified, and only the last party isn't? what is the mechanism
which causes that?

Thanks.