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

Previous Next

Full log

View this message in rfc822 format

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 56682 <at> debbugs.gnu.org, gregory <at> heytings.org, monnier <at> iro.umontreal.ca, visuweshm <at> gmail.com
Subject: bug#56682: Fix the long lines font locking related slowdowns
Date: Sun, 24 Jul 2022 08:16:33 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

> Which seems to be similar to slowdown due to font-lock in other cases?
> For example, scrolling with the same benchmark through xdisp.c takes
> 190 sec for the first time and 40 for the second time (when everything
> is already fontified); whereas without font-lock it takes 20.  So it
> sounds like font-lock generally slows down redisplay by such small
> factors?

Alas, I don't remember much about the exact figures I got when I
profiled this pre-21.  But a doubling of run time--after font-lock has
finished--doesn't appear to me to be entirely unplausible.

BTW, a memory that re-emerged right now: Interestingly, the number of
different text properties that the iterator checks, i.e. the number of
text property names like face, fontified, display, invisible, etc. that
the iterator checks, played on astonishing role back then.  And the
relation to performance wasn't linear either.  Which is why there's one
display property now, subsuming different subtypes.  Originally, the
subtypes were distinct properties, and display didn't exist.  Way before
Emacs 21.

Don't know if this is relevant for anything in this case.  I thought I
just mention that the interval tree might also have a potential for
improvement, if you will.  Amd another BTW: I was never 100% certain if
the interval tree is really always balanced because it didn't use an
algorithm that I knew and could recognize.

Previous Next

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