bug#56682: Fix the long lines font locking related slowdowns

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: gregory@heytings.org,  56682@debbugs.gnu.org,  monnier@iro.umontreal.ca
> Date: Wed, 27 Jul 2022 08:24:45 +0200
> 
> Eli Zaretskii <eliz@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.