From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stephen Berman via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#69385: 30.0.50; Long lines with bidi text slow down Emacs Date: Sun, 25 Feb 2024 19:03:24 +0100 Message-ID: <87zfvozaj7.fsf@gmx.net> References: <878r381pjk.fsf@gmx.net> <86msrowk0g.fsf@gnu.org> Reply-To: Stephen Berman Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="35089"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 69385@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Feb 25 19:04:11 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1reIrB-0008rP-F7 for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 25 Feb 2024 19:04:09 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1reIqr-0001O0-1H; Sun, 25 Feb 2024 13:03:49 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1reIqf-0001NN-FR for bug-gnu-emacs@gnu.org; Sun, 25 Feb 2024 13:03:37 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1reIqf-0003Ex-6l for bug-gnu-emacs@gnu.org; Sun, 25 Feb 2024 13:03:37 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1reIr4-0007pO-0m for bug-gnu-emacs@gnu.org; Sun, 25 Feb 2024 13:04:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Stephen Berman Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 25 Feb 2024 18:04:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 69385 X-GNU-PR-Package: emacs Original-Received: via spool by 69385-submit@debbugs.gnu.org id=B69385.170888423930073 (code B ref 69385); Sun, 25 Feb 2024 18:04:01 +0000 Original-Received: (at 69385) by debbugs.gnu.org; 25 Feb 2024 18:03:59 +0000 Original-Received: from localhost ([127.0.0.1]:35350 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1reIr0-0007oy-TA for submit@debbugs.gnu.org; Sun, 25 Feb 2024 13:03:59 -0500 Original-Received: from mout.gmx.net ([212.227.17.20]:43989) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1reIqy-0007oV-Fk for 69385@debbugs.gnu.org; Sun, 25 Feb 2024 13:03:57 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=s31663417; t=1708884205; x=1709489005; i=stephen.berman@gmx.net; bh=2HjBl/JHQCZoKDB/OgQFpO19uG0AreP5UcSrxV4T6s8=; h=X-UI-Sender-Class:From:To:Cc:Subject:In-Reply-To:References: Date; b=XqBTwrNeLp53CFN6W3rGSkVFzpTpQpVJZvJbSMhbgjNOGYZ6R7dZkHaaIORDbti5 VvSwLKgV1K0KewIUZhHR57xBOtnBQUJ24sKg+3uobQbXRt2WzZO+xjlZ3me4f6f5s ARMUgMuF+lm8s1z2DtkX0jfWIvUWCI1TRUhaHb4r4W2R4Tzf9IeNaJS5Lj6iEOA0L oDOpT86jRZPLK+rt5rgb2zObU5zWFrnMVubYBuJhOTgNk4PD9jm15U0c1hupU8adU 1eQymb+4tS0aQa+hpI3gSMd4wJGE5nN3PtTCYBSKE6RQlM9c7pl7rFVXgM8S8c2ah FwByB1NT15sAQGOhIw== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Original-Received: from strobelfs2 ([94.134.95.138]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1N9Mtg-1qszZx16SS-015LtZ; Sun, 25 Feb 2024 19:03:25 +0100 In-Reply-To: <86msrowk0g.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 25 Feb 2024 19:06:55 +0200") X-Provags-ID: V03:K1:moKfRDD42WGra31jzAosD/dUMkKrzTRLmISZ844Voz66jDClpQH 6pjbm+v77Xl+w7Dbkkv8UDvtavFrmxmNu35UhmoERoXlRoZXuyDxtX7w66piy+r0A3rVPt2 sHWa8oYBGlAoesOU3qaplS6z1nP7qCWj1DgGO6X0dVPHS7sX1Hm3gLd1N4lS5Ws15oG7pYt ZBgz+HT4mAUXyZcQZFoTw== UI-OutboundReport: notjunk:1;M01:P0:1xZFKul1Aho=;KOjlHoErzAk5Ds9Dbnvy2iNaQ0T A/QC5Gh6hnYC9vbaR1FQBC+8XwdyOSHUSC6WvQnVlyXocrfCAD/mwjskYGIL/Oq/zZ39oRROb yu7/OxmOS1VriQtBfy5gWX97vpSUXO1AC9Kva4uWzE1ANo0LKV6QQJCX+hqn+bKCqu1fvHO7j basxm6E/tdCFdfcro+h5X90n46H5MXmzWOVcNNPWtCkkITmzPBro7UMINmZjthYUm4zOPehjB 07I1VhzQvcBj5TJe1577gQiEHY05Ogbq1ZnplxB+CT8Nld4VNeD2GB9gf/k0C6DKAYyQxoc97 smtFCSwE20xhB3Ic3ffAM5uzaDOcp8AS2SJJs1XNKUe3fpTnu9I8Up5231gic8c297tSQBg93 8CYWFiScPvxsn90Phbu7NbNs7IiPJTr+9KyFga+YQph8bi8riLwhwRJxj+grDGS8gqvk19tWO QIFZmUhOfQ/EyxnwqF+gIu3tLQOwkbzwNKKGA3xYovanwA9e87C31LDU/Qjn6TE2IVvQ1AtPJ Rq+3S9eBICVYWTXzu+/IKoc4FQY4PBal5icKOAUP3mJEBvmg52lMDUHDqwlaycUwy5lH0Qd0L IdUzoOapUWEP1lmnBcYfOelz9fEDYtHLBxV32iJ2l2JJOonJiAdsZOxTcMcoqBflYoCQ2g8J9 atXORHn+VQV+4CubMhYwMyF6QQlkrBARWeH8tdZqmMVoNzfHF7tw6d8a0pHEVfoHMs9oJwjga 3JdeVLxHQJJI3g8MmSNbUZSEUmnJ3QvkSplE7Pk5E1CUWR1lFGnlM65GNC3P2NDndJLFUNqe X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:280632 Archived-At: On Sun, 25 Feb 2024 19:06:55 +0200 Eli Zaretskii wrote: >> Date: Sun, 25 Feb 2024 17:23:11 +0100 >> From: Stephen Berman via "Bug reports for GNU Emacs, >> the Swiss army knife of text editors" >> >> Displaying a buffer that contains a long line with bidirectional text >> greatly slows down Emacs. A simple reproduction is to copy the the >> Arabic example from etc/HELLO (`C-h h'), yank it into a buffer >> (fundamental-mode suffices), add " Hello ", and then create a single >> line consisting of a large number of copies of these strings; on my >> machine 500 copies clearly shows the slowdown, and with 800 copies it i= s >> much worse. > > It is not clear what exactly constitutes a slow-down in this recipe. > You describe how to create a test buffer, but not what you do > afterwards to demonstrate slow-down. Please fill the gaps. > > FTR, I tried C-f/C-b (no perceptible slow-down), C-v/M-v (likewise), > and C-n/C-p (no slow-down at the beginning of buffer, considerable > slow-down near the end: about 0.5 to 0.8 sec response time -- but this > is a non-optimized build; your optimized build should see about 0.1 > sec to 0.2 sec). Is this what you see? If not, please tell what did > you do and what did you see, and please describe it in detail and with > timings if possible. The first thing I tried, with both 500 and 800 copies, is M-> from point-min: with 500 it took ~4 seconds, with 800 ~10 seconds, and each time Emacs used 100% of one core for the duration (my machine has an i7-8700 processor with 6 cores/12 threads). After that even just invoking commands like `C-x 1' or `M-x' and entering something in the minibuffer shows a noticeable delay (several seconds) and 100% CPU. When I typed `C-n' at point-min in the 500 copy buffer and held down the key till the cursor froze, it took about a minute until it moved again (to point-max), during which the core used by Emacs stayed at 100%. >> There is no slowdown with a line of the same length consisting only of >> RTL or only of LTR text, nor with the above test line when >> bidi-display-reordering is set to nil in the buffer (but then, of >> course, the Arabic is not displayed correctly). > > That's not what I see: setting bidi-display-reordering to nil doesn't > affect the slow-down on my system in any perceptible way. Very strange: here, after setting bidi-display-reordering to nil, M-> and M-< are practically instantaneous and even holding down C-n or C-p traverses the entire buffer in a couple of seconds, with just a bit of stuttering. >> It seems that the long line optimizations added to Emacs 29 do not >> work with bidirectional text. > > Long line optimizations don't kick in until the lines are longer than > the value of long-line-threshold, by default 50000 characters. Since > 800 copies of the Arabic greeting don't reach that threshold, the > optimizations are not in effect at all in this case. Ah, ok. Then this is a different long-line issue. >> (FTR, I encountered this issue with a program of mine that generates >> Emacs Lisp files containing such long lines with bidirectional text. >> These files are not intended for display but I was examining one and >> experienced the slowdown.) > > If your real-life cases are all with Arabic text, then the reason is > likely not bidirectional reordering of RTL text by itself (although it > does slow down redisplay to some degree), but the fact that all of the > Arabic text gets shaped by HarfBuzz via composition-function-table, > which involves calls from the C code of the display engine into Lisp, > which then turns and calls back into C. This is relatively slow, but > we have no choice: Arabic shaping requires that all Arabic characters > be handed to the shaping engine for rendering, otherwise the display > will either be illegible for Arabic speakers or at least look ugly in > their eyes. I created a test buffer with 800 copies of the Hebrew HELLO text concatenated with " Hello " and found similar slowdowns with M-> and C-n as with the Arabic text. IIUC displaying the Hebrew script does not involve text shaping, or does it? > For now, I see no bugs here. Maybe if you tell more we will arrive at > something that is a real problem, but what I've read and saw until now > is what I would expect in these cases. I can try other tests if you can suggest any you think will help. Steve Berman