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

[Dmitry Gutov]

On 15.08.2022 17:03, Eli Zaretskii wrote:

> 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.

So we change the default, then?

  (setq font-lock-large-files '(narrow . 5000))

> My conclusion is that we do need to prevent uncontrolled
> widening in fontification-functions, if we want a scalable solution.

Do you mean the widening inside font-lock-fontify-region that's 
controlled by font-lock-dont-widen?

> How small or large should the narrowing be is a separate issue.

Right.

> 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.

I'm pretty sure that doing all that in Lisp is a good thing, and would 
be conducive to whatever improvements we might want to add later...

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

...but if you've sure in your decision, okay, please add that additional 
var which will decide the narrowing bounds for fontification-functions 
(and whether to narrow at all).

That should solve my immediate needs, and I'll try to avoid this subject 
from now on. Thanks.