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

Previous Next

Full log

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 56682 <at> debbugs.gnu.org, gregory <at> heytings.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#56682: Fix the long lines font locking related slowdowns
Date: Mon, 15 Aug 2022 18:52:41 +0300

On 15.08.2022 17:03, Eli Zaretskii wrote:

> I tested this branch with an unoptimized build and a 416MB file made
> of 23 copies of dictionary.json, after disabling show-paren-mode.
> 
> Observations:
> 
>    . With the default value of font-lock-large-files, which allows
>      font-lock to widen as it pleases, the initial M-> in takes 5 min
>      here.  That's way too long.  On master, this is instantaneous.
>    . Thereafter jumping into various random places inside the file is
>      much faster, but still takes between 1 min and 2.25 min -- again
>      too long, even if I divide by 10 to get an approximation to your
>      faster machine.  On master this takes maybe 1 sec, maybe less.
>    . Horizontal and vertical motion commands are as fast (or as slow)
>      as on master, which is not surprising.
> 
> Bottom line: with the default value of font-lock-large-files, this
> scales much worse than the master branch -- which again is no
> surprise.

So we change the default, then?

  (setq font-lock-large-files '(narrow . 5000))

> My conclusion is that we do need to prevent uncontrolled
> widening in fontification-functions, if we want a scalable solution.

Do you mean the widening inside font-lock-fontify-region that's 
controlled by font-lock-dont-widen?

> How small or large should the narrowing be is a separate issue.

Right.

> If we
> want to allow a more flexible control of that, we could introduce yet
> another variable exposed to Lisp, so that users and perhaps Lisp
> programs could tune that, instead of hard-coding the value as we do
> now on master.
> 
> I honestly don't see any reason to explore more sophisticated
> alternatives for where and how to narrow, until and unless major modes
> will on their side develop capabilities which will make such
> complications (both in code, but mainly on the user part) justified.

I'm pretty sure that doing all that in Lisp is a good thing, and would 
be conducive to whatever improvements we might want to add later...

> If you agree, I'll add on master a variable to control the narrowing
> when we call fontification-functions.

...but if you've sure in your decision, okay, please add that additional 
var which will decide the narrowing bounds for fontification-functions 
(and whether to narrow at all).

That should solve my immediate needs, and I'll try to avoid this subject 
from now on. Thanks.

Previous Next

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