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

[Gregory Heytings <gregory@heytings.org>]

>
> And since we already remove expensive hook functions, maybe that is 
> enough?  Or maybe we should use a different threshold for "expensive" in 
> buffers with long lines?
>

Do we?  As far as I can see, there is no time limit in safe_run_hooks. 
It could make sense to add one (or at least to clear out hook functions 
that have taken too long, as we already do it with functions that return 
an error... but doing that after the hook function returns is already too 
late, if it has taken say 30 seconds).

>>> Well, WDYT about a similar feature for very large files?  IOW, when 
>>> the buffer's size is above some threshold, turn on the 
>>> long_line_optimizations_p flag (which should perhaps be renamed to 
>>> better reflect its purpose) even if no long lines are seen?
>>
>> I was thinking about such a feature indeed.  But it would be separate 
>> from the long_line_optimizations_p one, because the optimizations to 
>> activate in both cases are different, and their thresholds are 
>> different, too.
>
> Different thresholds are easy to reconcile: the optimizations should be 
> turned on if either of the two thresholds is exceeded.  But why do you 
> say the optimizations will be different? what's wrong with using the 
> same optimizations, i.e. restrict the display code from accessing the 
> entire buffer?
>

I don't know exactly yet.  It seems to me that some of the optimizations 
for large buffers would be similar to the ones for long lines, and that 
many of the specific optimizations for long lines are not necessary for 
large buffers.  I think it would be better/safer to only enable the 
optimizations that are really necessary in each case.  But let's start 
thinking in more detail about the large buffer optimizations once the long 
lines optimizations are done, okay?