bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#56682: Fix the long lines font locking related slowdowns


From: Gregory Heytings
Subject: bug#56682: Fix the long lines font locking related slowdowns
Date: Thu, 04 Aug 2022 18:16:02 +0000


It's not really "almost instantaneous", moving point can take (depending on factors I do not understand at the moment) something between 0.2 seconds and 2 seconds.

I saw slower response when point was at a parentesis or a brace -- due to show-paren-mode. Try disabling it and see if that affects performance.


I forgot to mention that this is with show-paren-mode disabled.


Another problem could be the BPA algorithm in bidi.c, but in my testing setting bidi-inhibit-bpa non-nil didn't affect performance in any tangible way, with this file.


Indeed.


More accurately, Arabic text needs to call the shaping engine (HarfBuzz) for all the characters, whereas Hebrew does that only rarely (and not at all in locales.json). You can see from the composition rules in, respectively, lisp/language/misc-lang.el and lisp/language/hebrew.el that for Arabic, the entire range of Arabic characters is populated with composition rules in composition-function-table, whereas for Hebrew, only some relatively rare characters have non-nil rules.


Okay, thanks!

Hmmm... I still think it would be possible to do better. With the above recipe (M-g g 70000 RET C-n), composition_compute_stop_pos is called 627663 times and uses about 2 seconds of CPU time. What surprises me (and makes me believe it's perhaps possible to do better) is that it is called repeatedly with the same arguments. For example, when doing C-n it is called 26 times with charpos = 69980.

I'll see where these come from and whether some of them could be avoided.

Are you capable of running under perf and producing the profile of these commands? Because I wonder whether we correctly identify the main bottlenecks in these scenarios.


I can't speak in general, but in this particular scenario, the bottleneck is clearly composition_compute_stop_pos.

You didn't tell me whether it's okay to merge the branch with the latest changes?





reply via email to

[Prev in Thread] Current Thread [Next in Thread]