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

Previous Next

Full log

View this message in rfc822 format

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>, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: bug#56682: Fix the long lines font locking related slowdowns
Date: Tue, 2 Aug 2022 17:53:36 +0300

On 01.08.2022 14:01, Gregory Heytings wrote:
> 
>>> No, it happens when the buffer is opened.  Given the importance that 
>>> you and Stefan seem to give to that function, it is, with the patch I 
>>> sent in my previous post, called once on the whole buffer (without 
>>> any narrowing) when the file is opened.
>>
>> But if the buffer is not scrolled to the end, shouldn't it be called 
>> with a position that's close to the beginning?
>>
>> That shouldn't force the full buffer scan, meaning this call should 
>> complete quickly.
>>
> 
> I'm trying to reconcile two conflicting constraints.
> 
> It is necessary to add a locked narrowing around fontification-functions 
> and pre/post-command-hook to ensure that Emacs remains responsive.

Perhaps tweaking the value of syntax-wholeline-max could have a similar 
enough effect?

> At the same time, you and Stefan tell me that syntax-ppss does an 
> important job and will not do it correctly with such a locked narrowing, 
> IOW, that at least syntax-ppss should be called without a locked 
> narrowing.  But you also tell me that its result is cached so that a 
> full buffer scan isn't necessary anymore when it has happened at least 
> once.
> 
> So what I'm suggesting is to do a full buffer scan immediately, when the 
> file is opened, without any narrowing.  If that happens, later calls to 
> syntax-ppss inside fontification-functions and pre/post-command-hook 
> will use the cached result of the initial scan, and will do their job 
> correctly even with a locked narrowing.

syntax-ppss has two caches: one for the widened buffer (when point-min 
equals to 1), and another for narrowings. The latter cache is always 
cleared when point-min changes.

The latter cache works okay-ish for multiple-major-mode scenario, but if 
redisplay narrows with different limits, that would blow cache often. 
And if the whole chunk is big enough (i.e. bigger than the average 
distance between the cached syntax-ppss positions), that could actually 
result in syntax-ppss working slower than it could.

> Unless I misunderstand something, I think (and my tests seem to confirm) 
> that that would be a workable solution, provided that the initial scan 
> is reasonably fast, that is, at least six times faster than it is now.

I'm afraid this approach is too blunt to be a solution.

Previous Next

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