GNU bug report logs -
#62352
Very slow scroll-down-line with a lot of text properties
Previous Next
Full log
Message #22 received at 62352-done <at> debbugs.gnu.org (full text, mbox):
There is a behavior difference. I'm not sure what the exact reason is,
but the two different scrolls behave differently.
With a more complex case (~250 lines, each line is 150 characters long),
I can scroll "normally" from the bottom to the top in ~5 seconds (with
scroll-conservatively=101). The scrolling stutters. If I disable
font-lock, it won't get any faster, still ~5 seconds (but fluid).
With scroll-down-line, emacs freezes for 40 seconds, and when it
unfreezes, it didn't even reach the top.
I analyzed the issue little bit, the root cause of the slowdown is
composition handling (yet the composition feature is completely unused
by this example).
If I comment out these lines in composition_compute_stop_pos(), emacs
works better ("normal" scrolling becomes completely fluid,
scroll-down-line still freezes, but for a much shorter time):
/* if (charpos < endpos */
/* && find_composition (charpos, endpos, &start, &end, &prop,
string) */
/* && start >= charpos */
/* && composition_valid_p (start, end, prop)) */
/* { */
/* cmp_it->stop_pos = endpos = start; */
/* cmp_it->ch = -1; */
/* } */
It seems that emacs does a huge amount of redundant work by scanning
approximately the same area over and over again for composition properties.
I'm not sure how it is possible that you don't see any stuttering with
scroll-down-line. On my system it freezes for seconds with my original
example (and others can also reproduce it).
On 3/25/23 12:58, Eli Zaretskii wrote:
>> Date: Tue, 21 Mar 2023 21:58:05 +0000
>> From: Gregory Heytings <gregory <at> heytings.org>
>> cc: "Herman, Geza" <geza.herman <at> gmail.com>, 62352 <at> debbugs.gnu.org
>>
>>> However, are you saying that this is slower in Emacs 29 than it was in
>>> Emacs 28? If so, bisection will be appreciated.
>> FTR, I see the same behavior in Emacs 26, 27, 28 and 29 with that recipe.
> That figures: the relevant code didn't see any significant changes in
> the recent years.
>
> I also think the impression that C-n/C-p (with scroll-conservatively)
> are free of this problem is inaccurate. They are a bit faster,
> indeed, but in my unoptimized build I see the scroll taking almost the
> same time in both cases, close to 1 sec. I think OP's impression is
> based on where each of these crosses the threshold of Emacs being able
> to keep up with the repeated keystrokes, and that depends on both the
> auto-repeat rate and the CPU power, so it is different on different
> systems. E.g., in an optimized build I see no stuttering with
> scroll-down-line, either.
>
> So I think there's no bug here we need to look into, and I'm therefore
> closing this bug report.
This bug report was last modified 2 years and 116 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.