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

Previous Next

Full log

View this message in rfc822 format

From: Gregory Heytings <gregory <at> heytings.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 56682 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: bug#56682: locked narrowing
Date: Tue, 29 Nov 2022 17:10:27 +0000

>
> But I tried to see the effects of this new variable 
> (long-line-locked-narrowing-region-size), and it was a little puzzling.
>
> With the default value (500000) I open dictionary.json and start hitting 
> PgDn a lot. Syntax highlighting starts to look broken at the buffer 
> position that's around half that: at my last attempt it was at point 
> 259999.
>
> Looking at the code, there is indeed some halving going on, so maybe it 
> would be more easier to understand if the variable was called 
> locked-narrowing-radius, and used as such -- without division.
>

I considered naming it with "radius", but decided not to do it.  This is 
an implementation detail.  And the docstring says "region around point", 
from which an attentive reader can infer that half of the region will be 
before and half of it will be after point.  It does not seem worth the 
price to introduce separate cases for point at or near BOB and point at or 
near EOB.

>
> Another thing that bothered me when testing: going from eob to bob in 
> dictionary.json took ~4 seconds every time, independent of buffer being 
> edited or not. And that delay didn't show up anywhere in the profiler. 
> (setq bidi-inhibit-bpa nil) didn't help at all, but (setq 
> bidi-display-reordering nil) eliminated that delay.
>

Your analysis is not correct: the delay you see is due to show-paren-mode. 
Turn it off, and you'll see that going from EOB to BOB is instantaneous.

>
> And we'll probably come back to this question sometime later, but here's 
> something that looks like a regression. Editing dictionary.json is 
> snappier than dictionary-pp.json (same file but pretty-printed so 
> without long lines).
>

Unless I misunderstand what you mean, this cannot be a regression: editing 
dictionary.json was not possible with Emacs 28, editing dictionary-pp.json 
was.  Even if the former were now snappier than the latter, that would not 
be a problem in itself.

>
> Even with with common setup (and emacs -Q):
>
> 1. (setq long-line-locked-narrowing-region-size 50000)
> 2. (setq bidi-display-reordering nil)
> 3. Toggle show-paren-mode off, just in case.
> 4. electric-pair-mode off, same.
>
> typing in the latter file exhibits random pauses in redisplay up to 0.5s 
> (and sometimes 1s+). I haven't managed to catch the exact source of 
> those pauses (and they're longer with my personal config), but even 
> regular editing is slower: evaluating
>
> (benchmark 1 '(progn (insert " ") (redisplay t)))
>
> in dictionary.json reports something like 0.038906s, but in 
> dictionary-pp.json it prints ~0.136387s.
>

I cannot reproduce that.  With emacs -Q, with dictionary-pp.json and with 
show-paren-mode disabled, type C-s aan zich RET.  Now type some text: in 
both cases the effect is near instantaneous here, and I do not see any 
random pauses.

With your benchmark and with dictionary-pp.json:

- on current master, after C-s eman RET, I see ~100 ms, and after C-s aan 
zich RET, I see ~100 ms

- at ff57f30bee (30 July), after C-s eman RET, I see ~20 ms, and after C-s 
aan zich RET, I see ~2700 (!) ms

- at c59b8dfefa (30 Jun), after C-s eman RET, I see ~20 ms, and after C-s 
aan zich RET, I see ~2700 (!) ms

- with Emacs 28, after C-s eman RET, I see ~20 ms, and after C-s aan zich 
RET, I see ~3000 (!) ms

With your benchmark and with dictionary.json:

- with current master, after C-s eman RET, I see ~70 ms, and after C-s aan 
zich RET, I see ~70 ms

So there is no regression as far as I can see.

Previous Next

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