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

Previous Next

Full log

Message #1360 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: Sat, 13 Aug 2022 22:12:42 +0300

On 13.08.2022 20:26, Gregory Heytings wrote:
> 
>>> That's what I initially thought, too.  Now I tend to think that it 
>>> would be better to not decouple these two cases, because it would be 
>>> too expensive to distinguish the four possible cases, namely:
>>
>> I'm fairly sure that my branch demonstrates that there's nothing 
>> expensive about it.
>>
> 
> If you think this, it means you do not fully understand the problem, 
> sorry.  Detecting the presence of long lines in a buffer takes time, and 
> it takes more time as the buffer becomes larger.

How is that relevant? font-lock's performance does not depend on the 
presence of long lines.

>> It's just one commit, 20 additions, 10 deletions. It should take 2 
>> minutes max to read and understand it.
>>
> 
> As I said, I tested that commit.  And I understood it, too.  What you do 
> there does not even depend on the presence of long lines in the buffer 
> (or on the length of the buffer).

Exactly.

> Moreover it does not offer any 
> protection against modes which use widen in their font locking 
> routines.  Which was the main reason to add the locked narrowing feature.

The only modes we know that do that (CC Mode) are also incompatible with 
your code. Your "protection" breaks it.

And when CC Mode is fixed to work inside a narrowing, it will 
automatically become compatible with my proposal.

Previous Next

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