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>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 56682 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: bug#56682: feature/improved-locked-narrowing 9dee6df39c: Reworked locked narrowing.
Date: Tue, 31 Jan 2023 18:25:09 +0200

On 31/01/2023 17:14, Gregory Heytings wrote:
> 
>>
>> So we are removing all the stuff that prevented font-lock from slowing 
>> down redisplay when long lines are in the buffer?  IOW, something 
>> which we have for several months, and which so far brought up only one 
>> complaint?  Frankly, this makes no sense to me, unless we delay the 
>> pretest for another half year or so.  It's too late for such changes.
>>
>> Or am I missing something?
>>
> 
> I looked with a critical eye at the code I wrote, and concluded that the 
> cure is worse than the disease.
> 
> It's true that some slowdowns caused by font-locking are prevented by 
> locked narrowing, but:
> 
> 1. The slowdowns caused by font-locking were not the major cause of 
> slowdowns in buffers with long lines.  They were the "last step" to make 
> editing operations in such buffers as fast as possible, and my opinion 
> now is that that last step was a step too far.  Efficiency issues in 
> font locking routines are the responsibility of mode authors.  
> Efficiency issues in the redisplay routines are the responsibility of 
> Emacs, and have been dealt with.

FWIW, I happy you reached that POV.

> 2. Locked narrowing does not prevent all slowdowns caused by font-locking.
> 
> 3. Locked narrowing can create slowdowns (e.g. infinite loops) that do 
> not exist when it is not present.

This could be a pretty good argument. When testing in larger files, I 
did notice some performance kinks I could not easily explain, nor stably 
reproduce.

Speaking of additional slowdowns, though, at least in theory -- both 
syntax-ppss and tree-sitter drop their current parse result when 
point-min changes. So it an already fully parsed buffer (which applies 
more often to tree-sitter, though), scrolling through the buffer and 
fontifying should cause caches to drop to be recomputed again when the 
narrowing changes. Though that particular effect might not be too 
noticeable, since those features are rather fast in a 50000 region.

Previous Next

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