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

[Herman]

On 3/25/23 13:42, Eli Zaretskii wrote:
> > 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.
> This is a non-starter, unfortunately: the display engine _must_
> support character composition, or else some scripts will display
> incorrectly, and some features (like prettify-symbols-mode) will stop
> working.
I'm not saying that this is the solution. I just wanted to point out 
that emacs does unnecessary work. Note, even with this code commented 
out, composition still seems to work. Maybe it's buggy, of course. But 
the point is, it seems possible to fix this performance issue. Maybe 
it's a lot of work and it doesn't worth it. I understand that if this 
issue is closed because of this. But saying that this issue is not a 
(performance) bug is not correct, in my opinion. It is not unreasonable 
to expect that my example file can be scrolled without any problem.

> Get a faster computer, or make your keyboard auto-repeat rate lower?
Maybe there is a 2x single-thread performance factor between my computer 
and a current fast consumer desktop PC. It is highly unlikely that 
getting a faster computer will solve this problem.