|
From: | Herman |
Subject: | bug#62352: Very slow scroll-down-line with a lot of text properties |
Date: | Sat, 25 Mar 2023 13:33:53 +0100 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.1 |
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@heytings.org> cc: "Herman, Geza" <geza.herman@gmail.com>, 62352@debbugs.gnu.orgHowever, 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.
[Prev in Thread] | Current Thread | [Next in Thread] |