bug#56682: Fix the long lines font locking related slowdowns

[Dmitry Gutov]

00:32, August 13, 2022, Gregory Heytings <gregory@heytings.org>:

 
 I have eliminated two performance problems frim js-json-mode that are
 uncharacteristic for font-lock in general.

This is where we disagree: they _are_ characteristic of font locking in
general,

But they're not. Of course, modes might have problematic rules (font-lock-keywords are turing-complete, after all), but it might be just as easy to fix all the main major modes rather than hobble user experience.

Especially if we limit ourselves to modes that are likely to be used with large files.

So please go ahead and experiment, and report on your findings later.

in all modes (in core and in the wild) that use widen in their
font locking routines and/or do complex calculations far away from the
region that must be fontified.

But they don't do that. Even CC Mode doesn't do complex computations away from point during font-lock. It would be a bug if it did.

If we're talking about syntax-ppss, though, then it's properly amortized and in most simple workloads doesn't require recomputation.

The goal of this effort is not, and never was, to make editing the
dictionary.json file reasonably fast with an optimized build on a Core i9
computer. That file is, again, just an example. The goal of this effort
is to make editing any large file as smooth as possible, out of the box,
regardless of the major (and minor) modes that are are enabled, even with
a less efficient CPU, e.g. a Raspberry Pi computer, or a lower end laptop
with its CPU running at a lower frequency.

Then the goal failed because we don't disable bidi hpa? It has a much more noticeable effect on editing that font-lock.

And of course if we wanted to make everything as smooth as possible on every possible machine down to TI calculators, we would just disable all those features outright: and bidi, and font-lock, and show-paren-mode, and probably other things.

Which is why fixing js-mode, and adding a json-mode, as you did, is a "too
local" fix. Of course, that doesn't mean what you did is useless; it only
means that it cannot be considered as a general solution to the problem at
hand.

That's not what the branch contains.

I can only repeat that the only ways to improve font locking in a
non-local way (or at least, the only ways that were identified in the
discussions so far) are either to improve the speed of syntax-ppss by an
order of magnitude, in which case it would perhaps become feasible to
allow syntax-ppss to have access to the whole buffer, or to equip
syntax-ppss with heuristics to make it work "as well as possible" even
when it only has access to a portion of the buffer.

That's also easy to incorporate on the branch, as soon as somebody actually manages to implement that kind of heuristic for at least one major mode. But I'm not a fan of this approach TBH.