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

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: 56682@debbugs.gnu.org,  Gregory Heytings <gregory@heytings.org>,  Stefan
>  Monnier <monnier@iro.umontreal.ca>
> Date: Sat, 23 Jul 2022 10:11:04 +0200
> 
> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
> 
> > Gerd Möllmann <gerd.moellmann@gmail.com> writes:
> >
> >>> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
> >>>
> >>>> Font-lock       Output
> >>>> ------------------------------------------------------------
> >>>> on              GCs: 14 Elapsed time: 7.880788 seconds
> >>>   on, and large gc-const-threshold
> >>>                  GCs: 0 Elapsed time: 7.720531 seconds
> >     on, without scroll-bar
> >                    GCs: 15 Elapsed time: 5.574946 seconds
>       on without scroll-bar, auto-composition-mode off
>                      GCs: 15 Elapsed time: 4.166101 seconds
> >>>> off             GCs: 2 Elapsed time: 0.885791 seconds
> 
> Hm.

scroll-bar could be an issue only if we enter the new code that
doesn't use window_end_pos if it cannot be trusted.  Perhaps when
long-line optimizations are turned on for a buffer, we shouldn't try
to be holier than the Pope, and should use window_end_pos even if not
reliable?

And I've found a serious sink of CPU cycles under truncate-lines, and
installed a fix on the feature branch.  Gerd, if you have time to
eyeball the fix and comment on it, I'd appreciate.  It's commit
350e97d on the branch.  (I can post a more detailed explanation of
what I did and why, if that would help, because the code and the
functions it calls are somewhat tricky.)

After these changes, display of very long lines is quite reasonable,
when truncate-lines or truncate-partial-width-windows is in effect,
even without turning off font-lock and even in an unoptimized build.
Amusingly enough, show-paren-mode is now a serious performance killer
in these cases, because it puts overlays on buffer text, and that
disables a shortcut in the code that finds the next visible line
start, which is called a lot when lines are truncated.  Maybe we need
a smarter optimization there, one that doesn't immediately give up as
soon as it sees an overlay.  Hmm...