bug#69385: 30.0.50; Long lines with bidi text slow down Emacs

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: 69385@debbugs.gnu.org
> Date: Sun, 25 Feb 2024 21:36:46 +0100
> 
> > To make sure we are testing the same: what is the value of point-max
> > in that buffer?  I see something around 30k characters after making
> > 800 copies.
> 
> With 800 repetitions of the Arabic text from etc/HELLO ("السّلام عليكم")
> concatenated with " Hello " with no newlines, point-max is 16001.  So
> the length of the whole line is 16000 characters, and for the initial
> string " Hello السّلام عليكم", M-= returns 20, so for 800 copies
> point-max is what I would expect.  Do the Arabic characters in your font
> occupy two columns each?

No (and it doesn't matter, since I measured characters, not columns).
It's just that I copied more from the Arabic line than you did:
everything starting from the beginning of line.  Never mind, that.

> If the string I've tested is indeed that much shorter than what
> you've test, it's even more mysterious that I see such a slowdown
> and you don't...

Yes.

> > Then I don't know what is going on.  Maybe you have a very weak CPU or
> > something?  Or maybe your version of HarfBuzz is somehow much slower?
> 
> My CPU is Intel(R) Core(TM) i7-8700 CPU @ 3.20GHz, certainly not
> superfast but not superslow either, e.g. bootstrapping Emacs (without
> native compilation) takes just a few minutes (with native compilation
> it's a couple of minutes longer).  My HarfBuzz is version 8.3.0.

The CPU is fast.  My HarfBuzz version is much older, but I doubt that
HarfBuzz became so much slower for Arabic.  So it's very strange.  But
maybe it's worth to try downgrading to an earlier version, just to be
sure this is not the culprit?

> > Just to be sure: this is in "emacs -Q", and you see the same with many
> > different fonts used for Arabic, not just with a few of them?
> 
> Yes, this is with -Q.  The only fonts I've tried are Noto Naskh Arabic,
> DejaVu Sans, and Amiri.

Should be enough to draw conclusions, I think.

> Ok, I repeated the test with Hebrew without niqqud ("שלום") and indeed,
> M-> and M-< are much quicker and even holding down C-n and C-p is
> quicker (it does freeze, but unfreezes more quickly).  So it seems the
> bottleneck really is the shaping.

If, after starting Emacs, you set all the entries of Arabic characters
in composition-function-table to nil (e.g., using
set-char-table-range), do you see significant speedup?