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

Previous Next

Full log

Message #475 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>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#56682: Fix the long lines font locking related slowdowns
Date: Mon, 1 Aug 2022 01:42:24 +0300

On 01.08.2022 01:23, Gregory Heytings wrote:
> 
>>> Yes, I wasn't clear enough, I should have written "when the file is 
>>> large enough (say 1 GB), even without long lines".
>>
>> What kind of scenario are you thinking of that would exhibit this 
>> slowness in a 1 GB file?
>>
>> If we're talking about syntax-ppss only, regular editing operations 
>> (typing and deleting code) limited to, say, one screen should trigger 
>> only a rescan of a limited area inside such buffer.
>>
> 
> That's true, but with such big files, the initial scan is slow.  So the 
> scenario is simple: you open a big enough file, type M->, and C-p.  M-> 
> will be instantaneous, and C-p will take a while, because of syntax-ppss.

Yeah, ok. If you are going to visit EOB, a single full scan seems 
unavoidable. I don't think 'M->' should be instantaneous, though: to 
display the last page, you need to fontify it, and font-lock depends on 
syntax-ppss.

But one big slow scan (and how slow it is actually depends on a 
particular major mode) followed by responsive editing sounds much better 
than what we've had before.

So I would recommend against trying to solve this part right now. And 
yes, some faster approximations of syntax-propertize-rules are possible, 
especially if we ask individual language modes to provide "simpler" 
syntax rules.

Previous Next

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