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

[Herman]

On 3/25/23 15:02, Eli Zaretskii wrote:
> > I'm not saying that this is the solution. I just wanted to point out
> > that emacs does unnecessary work.
> How can Emacs know that this is "unnecessary work"?  You cannot know
> if the buffer contains any composable characters unless you search for
> them and fail to find them.
Properties don't appear out of thin air, emacs is the one who puts the 
properties to characters. So Emacs could build a parallel data structure 
which contains this information in a better searchable way. This data 
structure can be lazily constructed/updated, if it's needed.

Even, for my example problem, a simple 
"does-this-buffer-have-any-characters-with-composition-property" would 
be enough.

I'm not saying that this is the solution I want. I'm just saying this 
because you asked.

> > Note, even with this code commented
> > out, composition still seems to work. Maybe it's buggy, of course.
> If you comment out the call to find_composition, prettify-symbols-mode
> will stop working, and likewise any other features that use the
> 'composition' text property.
I commented out those lines I wrote, and I still see prettified symbols. 
I only commented out one find_composition call, all the other ones are 
still called. This call is bad, because it searches a 500-character 
area. A lot of other calls are fine because they only check one position 
(when limit<0).


> > But the point is, it seems possible to fix this performance issue.
> yes, it is possible to make the Emacs display faster by removing some
> of the features it provides.  But that is hardly the right way of
> "fixing" performance problems.
I didn't mean that. It can be made faster by using additional data 
structures/algorithms.
> > But saying that this issue is not a (performance) bug is not
> > correct, in my opinion.
> That's not what I said, though.
You said "So I think there's no bug here we need to look into". But I do 
think that there is a (performance) bug here.

> > > 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.
> My computer is a 10-year old machine.
What is the conclusion then? You don't have this problem for some 
reason, or you do some part of the repro steps differently so it doesn't 
preproduce for you. Gregory Haythings could reproduce it, as far as I 
understand. So the problem is not at my side.

I attached scroll_problem.cpp, for which this problem is more apparent, 
maybe this reproduces for you. This is the file for which emacs freezed 
for 40 seconds, when I moved the point to the bottom, and pressed and 
hold Shift-up for 1-2 seconds.

For this file, if I intentionally prettify a lot of characters with 
"(setq prettify-symbols-alist '(("a" . ?λ)))", then the problem 
disappears, because emacs doesn't have to search for 500 characters to 
find nothing, but each search stops after a small amount of characters. 
For me, this shows that there is a problem.

scroll_problem.cpp
Description: Text Data