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

[Gregory Heytings]

> I think such long lines happen in files that have very little except the 
> long line.  So duplicating it makes the use case much less important.

That's not correct.  Some files have indeed have a single long line, but 
others have more than one long line.  Duplicating the line in that file 
was just a quick way to generate a file with more long lines.  For 
example, a database dump will typically contain one long line for each 
table.  I have a database dump here with ~100 lines that are each about 1 
MB long, each of which is a single "insert into" statement.

> 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.

> But that's not a fundamental problem, or at least I don't yet see why it 
> would be fundamental.  It's something specific to isearch.el and to how 
> isearch-lazy-highlight is implemented.

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.

> 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.