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

[Dmitry Gutov <dgutov@yandex.ru>]

On 13.08.2022 20:54, Eli Zaretskii wrote:
>> Date: Sat, 13 Aug 2022 20:20:04 +0300
>> Cc:56682@debbugs.gnu.org, Eli Zaretskii<eliz@gnu.org>,
>>   monnier@iro.umontreal.ca
>> From: Dmitry Gutov<dgutov@yandex.ru>
>>
>> As soon as the file becomes very large, such that font-lock actually
>> becomes costly even in properly written major modes, we can still do one
>> of the two things: apply narrowing during font-lock, or fontify only the
>> beginning of the file.
> Fontifying only the beginning of the file doesn't help when the file
> is first shown at another point, like when Emacs or emacsclient is
> invoked with the +NN[:nn] argument, or the user uses saveplace or
> similar package.  That's admittedly rarer than starting at the
> beginning, but it's a valid use case, and I wouldn't like us to
> dismiss it.

The beginning of the file is the part of it which we can fontify quickly 
enough while still doing it correctly.

Starting with some position P, jumping to it will show a larger initial 
delay than you might be comfortable with. Maybe it's 1 MB, maybe 10 MB, 
maybe 100 MB. Or more. But such file size exists because syntax-ppss's 
performance depends linearly on the buffer size. So after that position 
we'll not fontify it anymore. That's really the simplest solution.

Because the main alternative on offer is to use narrowing and thus risk 
getting invalid syntax information. The effect is very noticeable in 
dictionary.json: you can just as easily get strings and non-strings 
inverted (the odds are pretty much 50/50). So the "don't fontify past X" 
strategy is simply based on the idea that no fontification is probably 
better than unreliable and obviously incorrect one.

Now, we could develop more complex approaches from there. But this can 
be a starting point, and the user option allows people to choose the 
strategy they're most comfortable with.