bug#62352: Very slow scroll-down-line with a lot of text properties

[Herman]

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@heytings.org>
> > cc: "Herman, Geza" <geza.herman@gmail.com>, 62352@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.