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

[Gregory Heytings]

> > They aren't, no.  Of course it all depends on where you are in the 
> > file, on your CPU, and so forth.  For me (with locked narrowing 
> > disabled, in dictionary.json, with emacs -Q) M-> takes about 3 seconds.
>
> And it's about 1.5s here.

So you're the lucky owner of a fast computer.  And using an optimized 
build.  Not everyone is in that fortunate situation.

> Once.

No, not once.  It happens every time you modify the buffer and move far 
enough in that buffer.

> > Likewise, if I do for example C-s aan, and then repeat C-s, whenever 
> > the next match is far enough in the buffer I see a delay of about 2 
> > seconds.
>
> Sounds like a performance problem inside isearch. I might take a look.

No, isearch is entirely agnostic about font locking.

> > Another test you can do is to lean on C-v after opening the buffer, 
> > you'll see that Emacs becomes very sluggish, sometimes I have to wait 
> > more than 5 seconds to avance from one screenfull.
>
> First of all, these aren't the tests Eli asked for or I performed. Why 
> don't you compare apples to oranges?
>
> Leaning on C-v isn't a scientific test anyway: it compares the speed of 
> two processes internal to Emacs (event handling and rendering), rather 
> than something objective.

It's yet another test meant to test Emacs' responsiveness, and it is as 
"objective" as possible: does Emacs choke or does it not?