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 16:59:46 +0100
> 
> On Mon, 26 Feb 2024 17:52:50 +0200 Eli Zaretskii <eliz@gnu.org> wrote:
> 
> >> From: Stephen Berman <stephen.berman@gmx.net>
> >> Cc: 69385@debbugs.gnu.org
> >> Date: Mon, 26 Feb 2024 16:17:53 +0100
> >>
> >> On Mon, 26 Feb 2024 16:22:59 +0200 Eli Zaretskii <eliz@gnu.org> wrote:
> >>
> >> >> Cc: 69385@debbugs.gnu.org
> >> >> Date: Mon, 26 Feb 2024 16:19:15 +0200
> >> >> From: Eli Zaretskii <eliz@gnu.org>
> >> >>
> >> >> > From: Stephen Berman <stephen.berman@gmx.net>
> >> >> > Cc: 69385@debbugs.gnu.org
> >> >> > Date: Mon, 26 Feb 2024 15:13:38 +0100
> >> >> >
> >> >> > On Mon, 26 Feb 2024 14:33:18 +0200 Eli Zaretskii <eliz@gnu.org> wrote:
> >> >> >
> >> >> > > 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?
> >> >> >
> >> >> > That's not so straightforward on this system, where I build system
> >> >> > packages from source, so downgrading HarfBuzz may require also
> >> >> > rebuilding packages that depend on it.  I have a somewhat older system
> >> >> > on this machine with HarfBuzz 7.1.0, so I can easily try that.  What
> >> >> > version of HarfBuzz are you using?
> >> >>
> >> >> I have 2.4.0 here.
> >> >
> >> > Btw, another possibility could be that this is specific to the Cairo
> >> > build.  So maybe try a build without Cairo.
> >>
> >> I did, and the slowdown seems just as bad as in the build with Cairo.
> >
> > Can you try the emacs-29 branch?
> 
> I already did and see the same slowdown with it as with master.  (Or did
> you mean try emacs-29 without Cairo?  That I haven't done, but given I
> saw no noticeable difference on master, I wouldn't expect to see one on
> emacs-29 either.)

I meant the emacs-29 branch in general, regardless of the exact
configuration.

I'm out of ideas, sorry.  The prominent effect of
bidi-display-reordering is especially puzzling.

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.