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

[Eli Zaretskii]

> Date: Sat, 30 Jul 2022 18:47:04 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: gerd.moellmann@gmail.com, 56682@debbugs.gnu.org, larsi@gnus.org, 
>     monnier@iro.umontreal.ca
> 
> >> 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

OK, but is it TRT to "punish" every one of these hooks for the
"crimes" of the few?  Maybe we should instead handle the problematic
ones locally, by exposing the long_line_optimizations_p flag to Lisp
(through an accessor), and then modifying those that misbehave to
"behave"?

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

You forget that we are talking about VM.

But let's not restart that argument, okay?

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

Sorry, I thought you were talking about a single-line file.

If JS mode wants to access the entire buffer for fontifications, then
IMO the problem is in JS mode, and should be fixed there.
narrow-to-region is available to Lisp programs as well ;-)

IOW, it isn't an infrastructure problem that needs to be fixed in
display code.  (It is even possible that tree-sitter integration will
fix this, or at least alleviate it, as a side effect.)