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>
> Cc: gregory <at> heytings.org, 56682 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
> Date: Wed, 27 Jul 2022 08:24:45 +0200
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > Gerd, the search for display properties and overlays in
> > forward_to_next_line_start, which disables the 'reseat' shortcut, is
> > because these could have strings as values, and those strings could
> > have embedded newlines, right? Or are there some other reasons?
>
> Correct, and I don't think there are other reasons.
Thanks, I installed an optimization, which makes Isearch faster in
such cases.
Turning off isearch-lazy-highlight in these cases is still a good
idea, though.
The next problem with long-and-truncated lines is that in many places
as part of redisplay we begin from the line's beginning and then go to
the position of point or the first visible X coordinate or somesuch.
This becomes slow when point is very far to the right, like near the
end of the line. A typical place in the code where this happens is at
beginning of display_line, where we call move_it_in_display_line_to to
get to it->first_visible_x. This could take seconds if there are many
overlays on the line, which is what happens, for example, if we are in
the middle of Isearch and isearch-lazy-highlight is turned ON.
(Searching for "</" in long-line.xml produces 9K overlays!)
I'll try to think how to speed up these move_it_* calls in those
cases. Ideas welcome.
This bug report was last modified 2 years and 8 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.