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

[Dmitry Gutov]

On 02.08.2022 05:31, Eli Zaretskii wrote:
> > Just like we do in such cases where an Emacs feature is not optimized
> > enough for a given use case: wait for the user to realize the situation
> > can and should be improved, and file a bug report/feature request.
> The intent of this activity is to make Emacs reasonably performant and
> responsive in the relevant use cases without asking them to wait for
> something that likely won't happen.
>
> IOW, in this case the Emacs developers, due to long-standing bug
> reports about this situation, recognized that it_can_  be improved,
> albeit in slightly unorthodox ways, and have taken the measures to
> optimize Emacs for the users.

It would be a shame to have the better-behaving (faster) major modes 
exhibit worse behavior that they could have because of the approach we 
choose to solve the long-lines problem.

Regarding the long-standing bug reports, we did solve a bunch of issues 
already. One major one, IIUC, was redisplay of already fontified text on 
long lines. Another piece of the puzzle was added by Stefan in 
15b2138719b340.

So perhaps we should re-evaluate the testing scenario to see where the 
current bottlenecks are. If we current main issue is the 55s spent in 
syntax-ppss, a more constructive approach would be to look into 
optimizing parse-partial-sexp. Or even give up on certain scenarios, 
admitting that waiting 55s once to visit the end of a 1 GB buffer is not 
so bad (and that could part could also be sped up by setting 
syntax-propertize-function to nil and using a very simple syntax table, 
for instance).