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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: gerd.moellmann <at> gmail.com, 56682 <at> debbugs.gnu.org, larsi <at> gnus.org, monnier <at> iro.umontreal.ca
Subject: bug#56682: Fix the long lines font locking related slowdowns
Date: Sat, 30 Jul 2022 21:34:44 +0300

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

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?

Previous Next

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