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

[Gregory Heytings]

> > Wouldn't it make sense to also limit the portion of the buffer to which 
> > pre-/post-command-hook have access (see below)?
>
> Those generally don't belong to the display department, so I'd hesitate 
> doing so.  Which pre-/post-command-hook functions did you find that 
> cause slowdown because of long lines.

jit-lock--antiblink-post-command

> > With that patch, I was able to open and edit a file with a single 50 GB 
> > (!) line, in js-mode.  Does that still not qualify as "arbitrarily 
> > large"?
>
> We don't even claim to be able to edit _files_ of arbitrary size 
> (because we are limited by fixnums).

That's theory, isn't it?  With 64-bit builds we are limited to files that 
are less than 2047 Po.  No computer on this planet has that much RAM.

> > I compared that with a 50 GB JSON file with 80 character wide lines. 
> > With that file it was necessary to disable font-lock-mode, which took 
> > too much time.
>
> How so?  We now restrict font-lock to a small region, so why does it 
> matter how much more stuff is there outside of the viewport?  What other 
> aspects of the line size still affect performance?

We do not restrict font-lock in large files _without long lines_, hence 
the difference.