GNU bug report logs - #56682
Fix the long lines font locking related slowdowns

Previous Next

Full log

Message #415 received at 56682 <at> debbugs.gnu.org (full text, mbox):

From: Gregory Heytings <gregory <at> heytings.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: gerd.moellmann <at> gmail.com, 56682 <at> debbugs.gnu.org, larsi <at> gnus.org,
 monnier <at> iro.umontreal.ca
Subject: Re: bug#56682: Fix the long lines font locking related slowdowns
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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.