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

Previous Next

Full log

Message #149 received at 56682 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: gerd.moellmann <at> gmail.com, 56682 <at> debbugs.gnu.org, gregory <at> heytings.org,
 monnier <at> iro.umontreal.ca
Subject: Re: bug#56682: Fix the long lines font locking related slowdowns
Date: Sun, 24 Jul 2022 18:05:21 +0300

> Date: Sun, 24 Jul 2022 17:35:19 +0300
> Cc: 56682 <at> debbugs.gnu.org, gregory <at> heytings.org, monnier <at> iro.umontreal.ca
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> 
> On 24.07.2022 08:50, Gerd Möllmann wrote:
> > Eli Zaretskii<eliz <at> gnu.org>  writes:
> > 
> >>> My bet is indeed on the mere presence of text properties, plus the
> >>> fact that we need to merge faces.  But I could well be wrong.
> > Can't say something about face merging, but "frequent" changes of faces
> > certainly have an effect on iterator performance.  It stops, looks up
> > properties again to determine the next stop pos, does what has to be
> > done for current properties...
> 
> But the problem is contingent on having long lines, isn't it?

Not necessarily, see the times I measured scrolling through xdisp.c,
which I posted earlier.  It could be that with long lines font-lock
just makes it slower still, to the point where it becomes unbearable.

> There must be some interplay between those circumstances. Not just 
> having to look up faces (relatively) a lot.

What else did you have in mind?

Previous Next

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