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

Previous Next

Full log

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: 56682 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 monnier <at> iro.umontreal.ca
Subject: Re: bug#56682: Fix the long lines font locking related slowdowns
Date: Wed, 10 Aug 2022 04:04:33 +0300

On 07.08.2022 23:21, Gregory Heytings wrote:
> 
>>> No, isearch is entirely agnostic about font locking.
>>
>> I wonder where it spends those 2 seconds, then.
>>
> 
> The answer is simple: it is not isearch that is slow, it's redisplay 
> that is slowed down by font locking.

Turns out, that was true. Unexpectedly, there was an area near the 
beginning of that file where a particular matcher (that I have now 
removed in fcd2d14db1) slowed things down considerably. The effect was 
such that fontifying a particular screen was about as slow as fontifying 
the end of the buffer.

That might or might not be a general design bug in font-lock with its 
MATCH-ANCHORED syntax (when a line is long, the "anchored" thing might 
lose its meaning).

isearch looks fast again, you're welcome to try.

>>> It's yet another test meant to test Emacs' responsiveness, and it is 
>>> as "objective" as possible: does Emacs choke or does it not?
>>
>> It's not a test of font-lock's performance, however. Because it 
>> compares that to a process that's internal to Emacs as well (moving 
>> across the buffer with C-v). Like, the faster we're able to make the 
>> latter command, the faster font-lock has to be to keep up. As an 
>> objective test, it's not meaningful.
>>
> 
> It is not by itself a test of font locking performance.  It becomes one 
> when you compare it with what you see (a) when font locking is 
> completely disabled, and (b) when font locking is enabled by constrained 
> by a locked narrowing.

What do you get from that comparison? That one thing is faster than the 
other? That accurate font-lock might take a little more time?

In any case, when I floor 'C-v' in dictionary.json now, whether 
narrowing is applied in 'handle_fontified_prop' or not, I see the buffer 
stutter around 2%, then go on and freeze around the 9% mark. When I 
release 'C-v' after waiting a while, it ends up at 12% or 14%.

Or if I go to EOB and floor 'M-v', both versions freeze almost right 
away. So it doesn't look like one is an order of a magnitude faster than 
the other, or at least not anymore.

C-n and C-p are also pretty sluggish with both versions.

Previous Next

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