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: Thu, 07 Mar 2024 12:12:51 +0100
> 
> Most of the Arabic words in the problematic file are enclosed in the
> bidirectional control characters POP DIRECTIONAL FORMATTING (#x202c) and
> RIGHT-TO-LEFT EMBEDDING (#x202b).  I did not add these characters, but I
> had copy-&-pasted most of the Arabic from a PDF file I did not create.
> I don't know if PDFs of Arabic text normally contain these control
> characters, but the consequences for Emacs were dramatic.  When I simply
> visited this file in Emacs (started with -Q) there was an immediate
> slowdown, and in top I could see Emacs using 100% of a CPU thread.  When
> I ran the end-of-buffer benchmark on this file, the result (with your
> patch) was:
> 
> (27.962602113 2 0.0226042269999999977)
> 
> However, the display of that result only appeared in the echo area after
> more than a minute (I timed it with a stopwatch).  At that point the
> mode line showed the buffer at 4% from the top, and the display remained
> frozen afterwards.  After several minutes during which Emacs consumed
> 100% CPU, and I had switched the focus away from the Emacs frame, the
> CPU consumption stopped, but as soon as I switch focus back to that
> frame, it went back to 100%.  The display never changed from showing the
> buffer at 4%, apparently being in some kind of infinite loop.  After
> about 15 minutes I started gdb, attached the Emacs process and produced
> a backtrace, which I've attached, in the hope it helps to diagnose the
> problem.
> 
> The problem seems to be certainly related the the bidirectional control
> characters, because I made a copy of the file and removed all
> occurrences of these control characters from it, and then ran the
> end-of-buffer benchmark, getting this result (with your patch):
> 
> (0.716104165 4 0.04223660400000001)
> 
> And the display updated normally and CPU consumption was normal.
> 
> Nevertheless, there seems to be something else besides the control
> characters involved in this issue, because as a futher test, I created a
> buffer consisting of more than 1000 copies of the test string
> concatenating the Arabic example in etc/HELLO and "Hello", and manually
> enclosed each Arabic word in the above control characters, but the
> benchmark result in this buffer was not significantly different from the
> result without the control characters (and similar to the above result
> for the copy of the problematic file without the control characters),
> and the display did not freeze.

Please submit a separate bug report, and please post an example of a
problematic file with the report.

Thanks.