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

From: Dmitry Gutov <[email-masked]>
Date: Tue, 26 Jul 2022 02:23:42 +0300

On 24.07.2022 18:05, Eli Zaretskii wrote:
>> Date: Sun, 24 Jul 2022 17:35:19 +0300
>> Cc: [email-masked], [email-masked], [email-masked]
>> From: Dmitry Gutov <[email-masked]>
>>
>> On 24.07.2022 08:50, Gerd Möllmann wrote:
>>> Eli Zaretskii<[email-masked]>  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.