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: Mon, 26 Feb 2024 18:12:04 +0100
> 
> On Mon, 26 Feb 2024 18:36:42 +0200 Eli Zaretskii <eliz@gnu.org> wrote:
> 
> [...]
> > Can you measure the time it takes to redraw the window after M->, with
> > and without bidi-display-reordering?  I'd like to have numbers here,
> > not just impressions.  For example, measure it with benchmark-run or
> > something similar.
> 
> On master started with -Q in a buffer containing a single line
> consisting of 800 repetitions of "السّلام عليكم Hello "

Oh, I think I see what's going on.  The buffer you create this way is
rendered as a paragraph with right-to-left base direction, right?
That is, it starts at the right side of the window, and C-f generally
moves to the left, yes?  By contrast, I thought you were doing this in
a buffer whose bidi-paragraph-direction is set to left-to-right, or
the text begins with Latin characters (as in "Arabic", the string the
begins the Arabic line in HELLO).

So now try your recipe, but set bidi-paragraph-direction to
left-to-right, or prepend a single ASCII character to the long line
(which will have the same effect on the base paragraph direction), and
then repeat your experiment, including the timings.  I think you will
see a big difference.

The reason is that, when a paragraph's direction is right-to-left,
inserting a new glyph into glyph matrices pushes all the previous
glyphs, thus reversing them on the fly.  Whereas in LTR paragraphs a
glyph is inserted by adding it to the end of the previous glyphs.  And
pushing is more expensive.  So now I understand why resetting
bidi-display-reordering had such a dramatic effect in your case: it
makes the paragraph render LTR as its side effect, which avoids the
costly pushing of glyphs.  In a very long line, this cost is very
high.

I will see if we can do better in this matter.