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

[Eli Zaretskii]

> Date: Tue, 26 Jul 2022 02:23:42 +0300
> Cc: gerd.moellmann@gmail.com, 56682@debbugs.gnu.org, gregory@heytings.org,
>  monnier@iro.umontreal.ca
> From: Dmitry Gutov <dgutov@yandex.ru>
> 
> >> 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?

Because they are long.  So there's more faces to encounter when going
from one line to another.

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

It isn't font-lock, at least not in all major modes.  It's the display
engine itself that sometimes needs to go to the beginning of the line.
When it does, going back gets slower with font-lock than without.
This is why you see slower redisplay when you go deeper into a long
line.