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

[Eli Zaretskii]

> Date: Thu, 04 Aug 2022 16:25:28 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: gerd.moellmann@gmail.com, 56682@debbugs.gnu.org, 
> monnier@iro.umontreal.ca, 
>     dgutov@yandex.ru
> 
> > I'm on the branch, so I am _after_ the optimizations.  I thought you 
> > said even after that the navigation is sluggish.
> 
> Yes, that's what I said indeed.
> 
> > I see somewhat slower response than in "normal" files, but my build is 
> > unoptimized, so where it takes 3 or 4 seconds, and optimized build 
> > should be almost instantaneous. And that looks good enough to me, since 
> > being a bit slower in such files is IMO fine.
> 
> 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.  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.

> > OK.  Text that goes through character compositions is expected to be 
> > slower in redisplay, because character composition in Emacs works by 
> > calling into Lisp.
> 
> So Arabic text goes through character compositions and Hebrew text 
> doesn't, is that correct?

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.

> > So I think we are good here, do you agree?
> 
> 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.