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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: 56682 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca, dgutov <at> yandex.ru
Subject: bug#56682: locked narrowing
Date: Wed, 30 Nov 2022 05:42:03 +0200

> Date: Wed, 30 Nov 2022 00:15:39 +0000
> From: 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>
> 
> 
> >> The result will be that the benchmark will report ~30ms both near BOB 
> >> and near EOB. So the long-lines-threshold thingy adds a regression 
> >> here.
> >
> > It's not a regression, it's the price we agreed to pay to detect whether 
> > the buffer contains long lines.  That detection happens dynamically, to 
> > catch cases when long lines are inserted in a buffer.
> >
> 
> After looking at this closely, it turns out that the change in 1c837c42c2 
> doesn't do what it was meant to do.  Sigh...  Dmitry, can you confirm that 
> the following change fixes this?

I think this is just one aspect of the issue.  The loop under this condition
"punishes" large buffers with no long lines because we search the entire
buffer top to bottom.  To make this scale better, I think we should only
search in some predefined vicinity of the window, perhaps the same region to
which we narrow the buffer when we do detect long lines.  We can then repeat
the search if point moves far away from its last value.

There's no need to search the whole buffer, that will cause delays in very
large buffers for no good reason.

We've talked about this a few months ago, and you said fixing this was part
of your todo.  I think now is the time.

Previous Next

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