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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Tue, 26 Jul 2022 20:55:05 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: gerd.moellmann@gmail.com, 56682@debbugs.gnu.org, monnier@iro.umontreal.ca
> 
> My conclusion is different: we will see more such cases, but only with 
> truncate-lines enabled, and that means that truncate-lines should be 
> disabled in such buffers.

I think these two issues are almost orthogonal.  Even if we decide to
disable truncate-lines in such buffers, we won't prevent users from
enabling it.  And if and when they enable it, we'd still like to give
them the best performance we can.  So speeding up the performance when
truncate-lines is enabled is still a worthy goal, although if that is
disabled in long-line buffers, that goal becomes less important.

> The fundamental problem is that with truncate-lines we cannot really 
> narrow the buffer to a smaller (contiguous) portion without creating 
> problems.

Yes, we need to find speedup opportunities that aren't solved by
narrowing.  But what I see for now is that the main bottleneck when
lines are truncated is reseat_at_next_visible_line_start, because we
call it each time we reach the right edge of a window, and need to
decide where to display the next screen line.  I've sped that up with
recent commits on the branch, but it is still very slow in some
situations, such as the one with isearch-lazy-highlight.  Another
situation which slows it down tremendously is when show-paren-mode
(which is ON by default nowadays) has a highlighted parenthesis
somewhere in the portion of the buffer outside of the viewport, the
part that reseat_at_next_visible_line_start needs to traverse to get
to the next newline.

I'm trying to speed up these situations as much as possible, and I
think it will serve us well even if we decide to turn off
truncate-lines in long-line buffers.