GNU bug report logs -
#56682
Fix the long lines font locking related slowdowns
Previous Next
Full log
Message #1893 received at 56682 <at> debbugs.gnu.org (full text, mbox):
Hi Gregory,
On 26/11/2022 16:14, Gregory Heytings wrote:
> I pushed another change to the feature/improved-locked-narrowing branch,
> which makes the locked narrowing around low-level hooks (and therefore
> around fontification-functions) configurable. I hope that addresses
> your concerns.
Thank you, this looks like a step in the right direction.
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.
Either way, though, if I set the var to a very large value, the syntax
highlighting looks okay.
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. So I'm still kind of
puzzled why we bother to restrict font-lock, but didn't do that with
this significantly more costly computation. The value of
long-line-locked-narrowing-region-size (big or small) has no effect on it.
Going back higher level, I wanted to repeat that don't understand why we
apply narrowing around font-lock in buffers with long lines, but not in
large buffers without long lines. Or vice versa.
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).
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.
Commit 89a10ffc (before the last merge) behaves the same, but going
further back, this commit from July behaves differently: b283e36cf19.
Emacs built from that version reports ~0.033022s in dictionary-pp.json
and 0.114781s at bob in dictionary.json (scrolling to the end
predictably freezes that Emacs build).
This bug report was last modified 2 years and 8 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.