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

[Eli Zaretskii <eliz@gnu.org>]

> 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>
> 
> The branch:
> 
> 1) Allows everyone interested to evaluate the performance of 
> unrestricted font-lock even in large files (single-line or not) and see 
> how big on a problem the delays caused by syntax-ppss actually are in 
> their experience. It's an important question.
> 2) Figure out the file sizes where syntax-ppss's performance really does 
> become a problem. That can give us data for better defaults later.
> 3) Play around with two easy solutions that we discussed previously: 
> narrowing during font-lock (one of the values for font-lock-large-files 
> pretty much matches the current behavior on master), or fontifying only 
> the first X characters (e.g. 1000000) of the buffer, and skipping on the 
> rest.
> 4) It should be plain to see that implementing additional approaches 
> should be easy enough. For instance, a hybrid like "fontify the first 1 
> MB correctly, and the rest - on best-effort basis". Although the value 
> '(narrow . 1000000) should provide behavior a very similar behavior 
> already. Maybe ever a better one: the boundaries are stable. Maybe sure 
> to try it together with (setq bidi-inhibit-hpa t): the result looks very 
> fast to me.

Thanks.

I tested this branch with an unoptimized build and a 416MB file made
of 23 copies of dictionary.json, after disabling show-paren-mode.

Observations:

  . With the default value of font-lock-large-files, which allows
    font-lock to widen as it pleases, the initial M-> in takes 5 min
    here.  That's way too long.  On master, this is instantaneous.
  . Thereafter jumping into various random places inside the file is
    much faster, but still takes between 1 min and 2.25 min -- again
    too long, even if I divide by 10 to get an approximation to your
    faster machine.  On master this takes maybe 1 sec, maybe less.
  . Horizontal and vertical motion commands are as fast (or as slow)
    as on master, which is not surprising.

Bottom line: with the default value of font-lock-large-files, this
scales much worse than the master branch -- which again is no
surprise.  My conclusion is that we do need to prevent uncontrolled
widening in fontification-functions, if we want a scalable solution.

How small or large should the narrowing be is a separate issue.  If we
want to allow a more flexible control of that, we could introduce yet
another variable exposed to Lisp, so that users and perhaps Lisp
programs could tune that, instead of hard-coding the value as we do
now on master.

I honestly don't see any reason to explore more sophisticated
alternatives for where and how to narrow, until and unless major modes
will on their side develop capabilities which will make such
complications (both in code, but mainly on the user part) justified.

If you agree, I'll add on master a variable to control the narrowing
when we call fontification-functions.