Re: cc-mode fontification feels random

["João Távora" <joaotavora@gmail.com>]

Eli Zaretskii <eliz@gnu.org> writes:

>> a big and complex buffer would give rise to one of these big and complex
>> JSON messages.
> Ask Dmitry about performance problems with native JSON support, and
> the effort we invested (a year ago?) into optimizing UTF-8 encoding of
> strings, to squeeze every last percent of performance.

As I remember, the biggest bottleneck was parsing and allocating Lisp
objects.  Commonly, it means parsing a big JSON message even if you're
only interested in a fraction of it (and this happens in LSP when
e.g. some servers decide to serve up huge buckets of diagnostics
unrelated to the current file being edited, for instance).  The json.c
parser is faster, but ultimately borks here, too.  

My idea at the time was to develop a technique to only parse the bits of
JSON we're interested in, which dramatically improved performance.  I
had a prototype for json.el lying around (can't seem to find it) based
on lazy evaluation.  If I remember correctly, Dmitry proposed another
technique based on a "path/selector language", which can also work but
is not quite so elegant IMO.

Of course, this is only useful if the starting assumption of much
useless JSON garbage is indeed true.  And I don't get a lot of bug
reports in Eglot about big-and-slow JSON, so it's been off the radar for
a while.

And again, for fontification, this point is probably moot if we're going
to integrate tree-sitter directly with direct access to the buffer
(which just makes sense).

João