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

Previous Next

Full log

Message #1246 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, stephen.berman <at> gmx.net,
 monnier <at> iro.umontreal.ca
Subject: Re: bug#56682: Fix the long lines font locking related slowdowns
Date: Wed, 10 Aug 2022 20:02:20 +0300

On 10.08.2022 19:08, Eli Zaretskii wrote:
>> Date: Wed, 10 Aug 2022 18:44:53 +0300
>> Cc: 56682 <at> debbugs.gnu.org, stephen.berman <at> gmx.net, monnier <at> iro.umontreal.ca
>> From: Dmitry Gutov <dgutov <at> yandex.ru>
>>
>> Shouldn't the scanner be limited by the same narrowing that the
>> long-line optimizations create? Given its existing effect on font-lock,
>> limiting bidi searches seems like a no-brainer.
> 
> Like I said: it _is_ limited.  But the limitation is smarter than just
> some arbitrary number of character positions, because it is tuned to
> this particular processing.
> 
> Note that the effect of it in this case is not as dramatic as
> font-lock: it does slow down C-n/C-p, but not catastrophically so,

It's much worse. In the aforementioned dictionary.json, with 
fully-featured font-lock (narrowing disabled in handle_fontified_props) 
the buffer is perfectly responsive to edit as long as I (setq 
bidi-inhibit-bpa nil). Even with show-paren-mode enabled.

Without that, however, simple navigation commands take a significant 
amount of time. These measurements are with show-paren-mode off:

Near BOB:

(benchmark 1 '(next-line 1)) =>
Elapsed time: 0.246551s
Elapsed time: 0.247237s
Elapsed time: 0.247392s

Near EOB:

(benchmark 1 '(next-line 1)) =>
Elapsed time: 0.059583s
Elapsed time: 0.040372s
Elapsed time: 0.059508s

> not
> like we've seen with the files we used for the long-lines speedups.
> And if someone does think it's a catastrophe, they can always disable
> the BPA, perhaps even globally,

That reminds me of "the user can always disable font-lock" and your 
dismissal of Alan's advice to change font-lock-maximum-decoration to 2, 
saying that we should have good editing performance OOTB.

> if they know they will never need to
> look closely at bidirectional text: the effects are hardly visible
> unless you actually read the text.

We could add (setq bidi-inhibit-bpa nil) to prog-mode, I suppose.

It already has a bidi-paragraph-direction setting anyway.

>> Alternatively, I would perhaps propose to perform said searching at two
>> junctions: when the buffer is visited (and the text is inserted and,
>> thus, unavoidably read), and when the buffer is saved (perhaps at that
>> point Emacs might have info about the added ranges, to avoid searching
>> through the whole buffer). The downside would be that the first added
>> R2L character might be displayed incorrectly until the buffer is saved.
> 
> This is impossible without a complete redesign of how the bidi display
> works: it saves no information in the buffer object, none whatsoever.
> The information is recomputed every time the display code is called,
> and only for the portion of the buffer that needs to be traversed or
> displayed; then it is discarded.  There are no caches of any kind that
> keep the information after redisplay has done its job.

Perhaps a cache similar to syntax-ppss one could do the job? Not sure 
what would be the trafeoffs, though. Like, how that would change the 
performance in the simple case.

Previous Next

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