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

From: Eli Zaretskii <[email-masked]>
Date: Sat, 30 Jul 2022 21:34:44 +0300

> Date: Sat, 30 Jul 2022 18:13:18 +0000
> From: Gregory Heytings <[email-masked]>
> cc: [email-masked], [email-masked], [email-masked], 
>     [email-masked]
> 
> 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.

Before considering these hooks, I'd consider window-scroll-functions
and window-*-change-functions, which _are_ run by redisplay.

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

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