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

[Dmitry Gutov]

On 24.07.2022 18:05, Eli Zaretskii wrote:
> > Date: Sun, 24 Jul 2022 17:35:19 +0300
> > Cc: 56682@debbugs.gnu.org, gregory@heytings.org, monnier@iro.umontreal.ca
> > From: Dmitry Gutov <dgutov@yandex.ru>
> >
> > On 24.07.2022 08:50, Gerd Möllmann wrote:
> > > Eli Zaretskii<eliz@gnu.org>  writes:
> > >
> > > > > My bet is indeed on the mere presence of text properties, plus the
> > > > > fact that we need to merge faces.  But I could well be wrong.
> > > Can't say something about face merging, but "frequent" changes of faces
> > > certainly have an effect on iterator performance.  It stops, looks up
> > > properties again to determine the next stop pos, does what has to be
> > > done for current properties...
> >
> > But the problem is contingent on having long lines, isn't it?
>
> Not necessarily, see the times I measured scrolling through xdisp.c,
> which I posted earlier.  It could be that with long lines font-lock
> just makes it slower still, to the point where it becomes unbearable.

Why with long lines, though?

> > There must be some interplay between those circumstances. Not just
> > having to look up faces (relatively) a lot.
>
> What else did you have in mind?

Some operation dependent on the length of the current line?

With font-lock, it seems to get progressively slower the farther you get 
along the current (long line).

E.g. you can have a long line spanning several screenfuls without line 
breaks. When the window is scrolled to the beginning, redisplay is 
relatively fast (I can press up/down arrows, and they seem responsive).

But if I scroll the window to the end of said long line, up/down 
commands become much less responsive.

Tested that with today's master and js-mode visiting a minified JS file.

Perhaps it's due to font-lock logic in that it has to match from the 
beginning of a line (not sure we'd want to abandon that promise, 
though). Or maybe something else.