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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sat, 25 Mar 2023 16:24:50 +0100
> Cc: gregory@heytings.org, 62352@debbugs.gnu.org
> From: Herman, Géza <geza.herman@gmail.com>
> 
> > 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.

It is not easy to maintain such a cache.  It needs to be kept up to
date at all times, and discarded/recreated when no longer accurate.
Any Lisp program can in principle add or remove text properties at any
moment, even inside a hook called by the display engine itself, such
as fontification-functions.

IOW, it is not as simple as you seem to think.

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

That would be a one-time condition.  It could become false before the
next redisplay cycle.  And checking this condition even once in a
large buffer with many text properties takes non-negligible time.

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

Please believe me when I say that such shortcuts aren't possible, at
least not in the simplistic way you are suggesting them.  There could
be some clever ideas that somehow do accomplish that, but I'd need to
see working code which implements them, not just ideas based on
simplifications of the real-life situations with which the Emacs
display code needs to cope in a production session.

It is no accident that any caches we do employ in the display code are
very localized and usually very short-lived; most are discarded when a
redisplay cycle ends.

> > 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.

There's a performance problem, I agree.  But as long as the design of
the display engine is what it is, I don't see how that can be helped,
in a way that will cope much better with the massive amount of face
properties as in these examples.

> >>> 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 didn't say the problem is on your side, I just mentioned the factors
that could cause it be more severe on your system than on mine.

> I attached scroll_problem.cpp, for which this problem is more apparent, 
> maybe this reproduces for you.

Yes, it does.  But only in scroll-down-line, not in scroll-up-line.

> 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.

Here it "freezes" for just 4 to 5 seconds, not 40.