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

From: Gregory Heytings <[email-masked]>
Date: Sat, 30 Jul 2022 18:47:04 +0000

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