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

[Gregory Heytings <gregory@heytings.org>]

>> No, isearch is entirely agnostic about font locking.
>
> I wonder where it spends those 2 seconds, then.
>

The answer is simple: it is not isearch that is slow, it's redisplay that 
is slowed down by font locking.

>> It's yet another test meant to test Emacs' responsiveness, and it is as 
>> "objective" as possible: does Emacs choke or does it not?
>
> It's not a test of font-lock's performance, however. Because it compares 
> that to a process that's internal to Emacs as well (moving across the 
> buffer with C-v). Like, the faster we're able to make the latter 
> command, the faster font-lock has to be to keep up. As an objective 
> test, it's not meaningful.
>

It is not by itself a test of font locking performance.  It becomes one 
when you compare it with what you see (a) when font locking is completely 
disabled, and (b) when font locking is enabled by constrained by a locked 
narrowing.