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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Thu, 28 Jul 2022 17:16:32 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: gerd.moellmann@gmail.com, 56682@debbugs.gnu.org, monnier@iro.umontreal.ca
> 
> > This is actually a bug in isearch.el: using window-end in a buffer under 
> > truncate-lines is simply wrong.
> 
> The measurements I gave were with isearch, but as I said you see the same 
> kind of slowdowns with motion and insertion commands.

No, that's not what I see.  Without the thousands of Isearch overlays
Emacs works much faster, almost 2 orders of magnitude faster.

> No, the measurements I gave were with isearch-lazy-highlight turned OFF. 
> And it is the fundamental problem, because it means that all display 
> routines have to deal with a very large amount of data.

By multiplying a very long and truncated line enough times you can
always make Emacs useless.  The speedups I have in mind scale linearly
with the number of such lines, so eventually, with enough such lines,
Emacs will always become very slow at some point, especially if the
window is hscrolled very far to the right.  That doesn't mean we
shouldn't try speeding up the code: someone just told me that the
perfect is the enemy of the good.

> > I still have one or two ideas to try, and they don't involve anything as 
> > complex as some new kind of narrowing.
> 
> Okay, so I'll wait a bit more.  I'd like to reach a conclusion as to 
> whether truncate-lines should be turned off when long_line_optimizations_p 
> is on before merging the branch into master.

That's unrelated.  The branch was created for your work on font-lock,
and if you are done with that, feel free to land it on master.  I can
continue working on master, and/or will create a feature branch if I
feel it's justified.

Thanks.