GNU bug report logs - #56682
Fix the long lines font locking related slowdowns

Previous Next

Full log

Message #185 received at 56682 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: gerd.moellmann <at> gmail.com, 56682 <at> debbugs.gnu.org, gregory <at> heytings.org,
 monnier <at> iro.umontreal.ca
Subject: Re: bug#56682: Fix the long lines font locking related slowdowns
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: 56682 <at> debbugs.gnu.org, gregory <at> heytings.org, monnier <at> iro.umontreal.ca
>> From: Dmitry Gutov <dgutov <at> yandex.ru>
>>
>> On 24.07.2022 08:50, Gerd Möllmann wrote:
>>> Eli Zaretskii<eliz <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.