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

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ihor Radchenko <yantar92 <at> gmail.com>
Cc: 56682 <at> debbugs.gnu.org, gregory <at> heytings.org, monnier <at> iro.umontreal.ca,
 dgutov <at> yandex.ru
Subject: Re: bug#56682: Fix the long lines font locking related slowdowns
Date: Tue, 16 Aug 2022 15:10:23 +0300

> From: Ihor Radchenko <yantar92 <at> gmail.com>
> Cc: monnier <at> iro.umontreal.ca,  dgutov <at> yandex.ru,  gregory <at> heytings.org,
>   56682 <at> debbugs.gnu.org
> Date: Tue, 16 Aug 2022 19:30:11 +0800
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> Also, I just checked some of my org files and found a >15k chars long line.
> >
> > 5k shouldn't present a problem, especially when some/most of it is
> > invisible (as frequently is the case in Org).  15k might be a problem,
> > indeed, depending on what's there.  However, since you never
> > complained about long lines until this day, I guess it isn't such a
> > big problem.
> 
> You are likely right. Note that this branch of the discussion mostly
> started from me clarifying data about some large Org files. I did not
> imply that Org files commonly have very long lines. Simply large-sized
> Org files are more common (5-20Mb).
> 
> Also, regarding most of the lines being invisible. Unless I miss
> something, jit-lock actually tries to trigger fontification in the
> invisible lines when we have something like:
> -- <window top>
> * headline
> <Mbs of invisible text hidden using 'invisible text property>
> * another headline
> -- <window bottom>

That 's true, but:

  . jit-lock is called by the display engine, and the display engine
    skips invisible text
  . jit-lock calls the fontification functions with a relatively small
    chunk of buffer text

The result of these two factoids is that (a) jit-lock shouldn't
attempt fontifications, except when the un-fontified text starts
exactly at the beginning of invisible text; and (b) even if
fontifications are invoked on invisible text, it should be a
relatively small chunk of it.

More importantly, when I wrote the above, I wasn't thinking about
fontifications, I was thinking about the rest of the display code,
which always skips invisible characters, and skips them using
relatively fast search for text properties, not the much slower
iteration through the text one character at a time.

Previous Next

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