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

[Eli Zaretskii]

> Date: Mon, 15 Aug 2022 18:52:41 +0300
> Cc: 56682@debbugs.gnu.org, gregory@heytings.org, monnier@iro.umontreal.ca
> From: Dmitry Gutov <dgutov@yandex.ru>
> 
> 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))

No, I want a simple variable that just gives the size of the narrowed
region, with nil meaning don't narrow at all.

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

No, I mean _any_ widening in _any_ function placed on the
fontification-functions hook.

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

No, because quite a few packages use jit-lock-register to run stuff
that is not font-lock at all, and I don't want that to slow down
redisplay when long lines are involved.  And trying various values of
a variable exposed to Lisp is easy enough.

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

Will do soon.

Thanks.