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