GNU bug report logs - #56682
Fix the long lines font locking related slowdowns

Previous Next

Full log

View this message in rfc822 format

From: Gregory Heytings <gregory <at> heytings.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: gerd.moellmann <at> gmail.com, 56682 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca, dgutov <at> yandex.ru
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?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.