|
From: | Herman |
Subject: | bug#62352: Very slow scroll-down-line with a lot of text properties |
Date: | Sat, 25 Mar 2023 16:24:50 +0100 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.1 |
On 3/25/23 15:02, Eli Zaretskii wrote:
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.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.
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.
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).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 didn't mean that. It can be made faster by using additional data structures/algorithms.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.
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.But saying that this issue is not a (performance) bug is not correct, in my opinion.That's not what I said, though.
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.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.
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
[Prev in Thread] | Current Thread | [Next in Thread] |