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

Previous Next

Full log

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

From: Gregory Heytings <gregory <at> heytings.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>,
 56682 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>,
 visuweshm <at> gmail.com
Subject: Re: bug#56682: Fix the long lines font locking related slowdowns
Date: Mon, 25 Jul 2022 20:49:14 +0000

I pushed another improvement to the branch.  Now motion in a font-locked 
buffer is almost as fast as in a non font-locked one; I don't think it's 
possible to make further significant improvements.

It turns out that the motion slowdowns in font locked-buffers were caused 
only indirectly by font locking.  What happens is that in a font-locked 
buffer, get_next_display_element calls next_element_from_buffer which uses 
handle_stop (and therefore compute_stop_pos) to position the iterator on 
the next element.  In a file such as long-line.xml, there are many more 
stop positions when the buffer is font locked, roughly 100 times more. 
The solution is to make back_to_previous_visible_line_start do something 
closer to what it promises, namely "Set IT's current position to the 
previous visible line start."  Previously it moved IT to the beginning of 
the (temporarily narrowed) buffer, which was already much better than 
moving it to the beginning of the line, but not enough to make motion 
commands fast.

Previous Next

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