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: monnier <at> iro.umontreal.ca
Cc: 56682 <at> debbugs.gnu.org, gregory <at> heytings.org
Subject: bug#56682: Fix the long lines font locking related slowdowns
Date: Sat, 23 Jul 2022 19:19:39 +0300

> Cc: 56682 <at> debbugs.gnu.org, gregory <at> heytings.org
> Date: Sat, 23 Jul 2022 19:15:26 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> 
> > From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> > Cc: gregory <at> heytings.org,  56682 <at> debbugs.gnu.org
> > Date: Sat, 23 Jul 2022 11:46:37 -0400
> > 
> > >> AFAIK if the buffer has not been modified (including things like
> > >> changing `window-start` or `point`), then a redisplay will just not
> > >> run jit-lock (and hence font-lock) at all, no matter how thorough.
> > > But the fact is without font-lock the response is faster by a large
> > > factor.  So something, somewhere, still depends on font-lock.
> > 
> > Yes, that's the part that we need to explore.
> > Maybe font-lock *is* run somehow?
> > Or maybe it's just the mere presence of text properties?  (Or overlays?)
> 
> 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.

Btw, I think the best tool for determining this is run-time profiling,
such as with perf on GNU/Linux.

Previous Next

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