[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#57207: 29.0.50; Fontification is slow after e7b5912b23 (Improvements
From: |
Eli Zaretskii |
Subject: |
bug#57207: 29.0.50; Fontification is slow after e7b5912b23 (Improvements to long lines handling) |
Date: |
Tue, 16 Aug 2022 15:43:31 +0300 |
> Date: Tue, 16 Aug 2022 12:17:10 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: 57207@debbugs.gnu.org, yantar92@gmail.com
>
> > We update UNCHANGED_MODIFIED in mark_window_display_accurate_1, so if
> > the window completes its redisplay cycle "normally", whatever jit-lock
> > does shouldn't matter for the next redisplay cycle, because
> > UNCHANGED_MODIFIED will be updated from MODIFF.
>
> Hmmm... The fact is that using CHARS_MODIFF avoids rescanning the buffer
> when "too many" text properties are changed. With xdisp.c, the long lines
> detection code is not called anymore when scrolling through the (initially
> unfontified) buffer. The original bug description (additional delays
> between redisplay cycles in a large buffer) is probably caused by
> needlessly executing that long lines detection code, at least that's
> consistent with my earlier experiments.
That was also my guess.
(I do see the long-line detection code sometimes called while
scrolling through xdisp.c, but that's probably because my Emacs is
unoptimized, and so cannot keep up with the auto-repeat rate of my
keyboard when I lean on C-v; and so some redisplay cycles are
interrupted prematurely and don't get to
mark_window_display_accurate_1.)
> > What I don't understand is why enlarging the value of the threshold
> > causes Emacs to "hang". If it really is some kind of infloop, I cannot
> > understand how issues like outdated UNCHANGED_MODIFIED could cause that
> > only for some value of the threshold, but not for a smaller value. I
> > thought perhaps there are lines longer than 10000 characters, but none
> > beyond 100000, but this turns out to be false, so with both values of
> > the threshold that loop in redisplay_window should have scanned the
> > entire buffer top to bottom in both cases...
> >
> > So I suspect something else is at work here.
> >
>
> Yes, I suspect that this is another bug, separate from the original bug
> Ihor described. It might be a bug in find_newline1, in the backtrace he
> sent, find_newline1 returns 10568710 and later 9679581. It's not clear
> however if that's in the same loop (he asked gdb to "continue" between the
> two).
This part of my confusion is now off the table. So the primary
suspect is something that causes UNCHANGED_MODIFIED fail to be
updated.
- bug#57207: 29.0.50; Fontification is slow after e7b5912b23 (Improvements to long lines handling), (continued)
- bug#57207: 29.0.50; Fontification is slow after e7b5912b23 (Improvements to long lines handling), Eli Zaretskii, 2022/08/15
- bug#57207: 29.0.50; Fontification is slow after e7b5912b23 (Improvements to long lines handling), Gregory Heytings, 2022/08/16
- bug#57207: 29.0.50; Fontification is slow after e7b5912b23 (Improvements to long lines handling), Eli Zaretskii, 2022/08/16
- bug#57207: 29.0.50; Fontification is slow after e7b5912b23 (Improvements to long lines handling), Ihor Radchenko, 2022/08/16
- bug#57207: 29.0.50; Fontification is slow after e7b5912b23 (Improvements to long lines handling), Gregory Heytings, 2022/08/16
- bug#57207: 29.0.50; Fontification is slow after e7b5912b23 (Improvements to long lines handling), Eli Zaretskii, 2022/08/16
- bug#57207: 29.0.50; Fontification is slow after e7b5912b23 (Improvements to long lines handling), Gregory Heytings, 2022/08/16
- bug#57207: 29.0.50; Fontification is slow after e7b5912b23 (Improvements to long lines handling), Ihor Radchenko, 2022/08/16
- bug#57207: 29.0.50; Fontification is slow after e7b5912b23 (Improvements to long lines handling), Gregory Heytings, 2022/08/16
- bug#57207: 29.0.50; Fontification is slow after e7b5912b23 (Improvements to long lines handling), Eli Zaretskii, 2022/08/16
- bug#57207: 29.0.50; Fontification is slow after e7b5912b23 (Improvements to long lines handling),
Eli Zaretskii <=
bug#57207: 29.0.50; Fontification is slow after e7b5912b23 (Improvements to long lines handling), Ihor Radchenko, 2022/08/15
- bug#57207: 29.0.50; Fontification is slow after e7b5912b23 (Improvements to long lines handling), Eli Zaretskii, 2022/08/15
- bug#57207: 29.0.50; Fontification is slow after e7b5912b23 (Improvements to long lines handling), Ihor Radchenko, 2022/08/15
- bug#57207: 29.0.50; Fontification is slow after e7b5912b23 (Improvements to long lines handling), Eli Zaretskii, 2022/08/15
- bug#57207: 29.0.50; Fontification is slow after e7b5912b23 (Improvements to long lines handling), Eli Zaretskii, 2022/08/15
- bug#57207: 29.0.50; Fontification is slow after e7b5912b23 (Improvements to long lines handling), Ihor Radchenko, 2022/08/16
- bug#57207: 29.0.50; Fontification is slow after e7b5912b23 (Improvements to long lines handling), Eli Zaretskii, 2022/08/16
- bug#57207: 29.0.50; Fontification is slow after e7b5912b23 (Improvements to long lines handling), Gregory Heytings, 2022/08/16
bug#57207: 29.0.50; Fontification is slow after e7b5912b23 (Improvements to long lines handling), Ihor Radchenko, 2022/08/16
bug#57207: 29.0.50; Fontification is slow after e7b5912b23 (Improvements to long lines handling), Eli Zaretskii, 2022/08/14