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: Mon, 26 Feb 2024 22:47:21 +0100 Message-ID: <87a5nmgaom.fsf@gmx.net> References: <878r381pjk.fsf@gmx.net> <86msrowk0g.fsf@gnu.org> <87zfvozaj7.fsf@gmx.net> <86edd0wdbs.fsf@gnu.org> <87r0h0z3fl.fsf@gmx.net> <868r37wgkx.fsf@gnu.org> <87zfvnfh4d.fsf@gmx.net> <86v86bux3w.fsf@gnu.org> <86ttlvuwxo.fsf@gnu.org> <87r0gzfe5a.fsf@gmx.net> <86r0gzusrx.fsf@gnu.org> <87msrnfc7h.fsf@gmx.net> <86o7c3uqqt.fsf@gnu.org> <87il2bf8uz.fsf@gmx.net> <86bk83uj9a.fsf@gnu.org> Reply-To: Stephen Berman Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="6195"; 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 Mon Feb 26 22:47:59 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 1reipK-0001NX-MF for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 26 Feb 2024 22:47:58 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1reip1-0001YZ-6y; Mon, 26 Feb 2024 16:47:39 -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 1reioz-0001YA-Fq for bug-gnu-emacs@gnu.org; Mon, 26 Feb 2024 16:47: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 1reioy-0005ZT-V8 for bug-gnu-emacs@gnu.org; Mon, 26 Feb 2024 16:47:37 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1reipO-0001Bm-5b for bug-gnu-emacs@gnu.org; Mon, 26 Feb 2024 16:48: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: Mon, 26 Feb 2024 21:48:02 +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.17089840754544 (code B ref 69385); Mon, 26 Feb 2024 21:48:02 +0000 Original-Received: (at 69385) by debbugs.gnu.org; 26 Feb 2024 21:47:55 +0000 Original-Received: from localhost ([127.0.0.1]:41594 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1reipH-0001BC-5j for submit@debbugs.gnu.org; Mon, 26 Feb 2024 16:47:55 -0500 Original-Received: from mout.gmx.net ([212.227.15.18]:36545) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1reipF-0001Ap-4j for 69385@debbugs.gnu.org; Mon, 26 Feb 2024 16:47:53 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=s31663417; t=1708984041; x=1709588841; i=stephen.berman@gmx.net; bh=t9YgE4kYSbMionO/nPgHO3RZBIf6y+MzuEZEWK2xqHQ=; h=X-UI-Sender-Class:From:To:Cc:Subject:In-Reply-To:References: Date; b=ZIvLvpnWAjgRpnYCxlEmyPZRYyrlzC7RPOqk08QHIErmt1rS5V+A5qTkR87+ktP9 sjadfeOY3or+8xd5plpS4kXDij4VgevFi6xPQIIfsECj2jWCFqwgjCyKDZ+9lo7kj Hg9qJdq6+A9wftjdCVaGX7rlDzt2ouzlcCrpqdytEv/PuIJy0gJ1Vc9ztZrZc4fa8 JvTUyBk02iZKqm6Oal5xtd9gpVMGSHcSIBmYZv+I2xZw2I6PA1CHNphB1EgAO4DSW EuItQEZ5zgtJAyz5S/u7TJx3T+F2IzyDAQI2YItGpLaXb8JGxh/BFhRs8GYvw2tEu 2hvP2wl4pZil2ZKtfA== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Original-Received: from strobelfs2 ([94.134.95.66]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1M6llE-1rXakR2ErW-008NMx; Mon, 26 Feb 2024 22:47:21 +0100 In-Reply-To: <86bk83uj9a.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 26 Feb 2024 21:18:25 +0200") X-Provags-ID: V03:K1:jibFTTZTCKiJ2jVuvsHGjkZd5F3jbpuvyaohNZpjxf9fqV/bvrq jf6hGNnRnmgkwsCbwE4d6h/QGGPFqpEHr9bKsgnJrpqwvIc5fDUiQR2xmnjJDN96Wds7HcG pkoBlAJK5JaWunEQvea8mkZpUUrkrN2QjnNB5pWeeWCxKTGHCn9v6g2KrtLYvUw0+o7z3Uk pSe2PFljRg59JzEil0V3w== UI-OutboundReport: notjunk:1;M01:P0:TsYgc0q7OKs=;BBz5yH6WKLqsNJmbsX5lfjR2aoj 2IkVTKnbzusaZNQtmpKYu7SBUfd6a6ibNvQBfBSkxLA+/knITO0wvwheFjbyOS7YktufLD4fX 7er6xXUWFkN6dQbzbDTDWUxpiPxC7/xNRTAVt+UidOJjfDAF+APQ/5vPOXgZSFMplga/5QMX3 keK9LLgJfi9I7/eWCT/EZTW4otlLttkSTL2OFcGIEhwTD5aUUvgEzo0qX8xIln+Rn991MvZ/A q2g4vIHNmwR60ZW4mAB3nygZGt8BRYr0oMttiqEjrMrTmEB36i4akpkRT9jia/Q0cfndfF0Ac Vp9H7mnK0rhMTrJA/GQ3Fal3d7Ru8TgoxXpDJHTwdYCDHpoX4huYyqAgiU8CyzxtExhqh7BG9 m4s8KF2exizlDJ5g+D9ih3iDcenaHmCpBZIHzQPIHBFdNyLNnWyybz3Nt/27MinViYvE0xCXs zYOZzy2p97ZtvYFqWv4CK6lbIL6BxQIoO/2HdbRoroAtLNHGB5v1NvukuMON5Q7jNt9ZAnX8i 4O53we2XyW6lzfvt+YqQaPHeAxAsZxM2dXASGxYHm7OD4ChUzckNmAhfNcmbfZYE1x89pn429 BNIvQMZOFLtWaI+qeaHhYFvVOusWYRkSPPdx8vshvSn3+Vzg2KWKOIs3gdBP72kWUYLhstwib 4+3OWOcnU339O2TkjRCrtMOOzze3YIjvywwSX2zAiDSytSb2UflnKX+1rfVAUalF51j0vVWPM azuySMlbhFXjxjstb8m0Yu1B28Dhm0LupTiNLzfeLmlnvXPJwfdNumdiTCzpUeiU9M0Ka/yP 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:280707 Archived-At: On Mon, 26 Feb 2024 21:18:25 +0200 Eli Zaretskii wrote: >> From: Stephen Berman >> Cc: 69385@debbugs.gnu.org >> Date: Mon, 26 Feb 2024 18:12:04 +0100 >>=20 >> On Mon, 26 Feb 2024 18:36:42 +0200 Eli Zaretskii wrote: >>=20 >> [...] >> > 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. >>=20 >> On master started with -Q in a buffer containing a single line >> consisting of 800 repetitions of "=D8=A7=D9=84=D8=B3=D9=91=D9=84=D8=A7= =D9=85 =D8=B9=D9=84=D9=8A=D9=83=D9=85 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? Correct. > 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. I created the test buffer now by first typing "Hello" and the inserting " =D8=A7=D9=84=D8=B3=D9=91=D9=84=D8=A7=D9=85 =D8=B9=D9=84=D9=8A=D9=83=D9=85= " on the right, so the base paragraph direction was LTR. Then I ran the benchmarks, and there is indeed a big difference, but one that I think will surprise you. First, the timing for the LTR run with bidi-display-reordering set to nil was: (0.035104007 0 0.0) This is, unsurprisingly, almost the same as the corresponding test run with RTL base paragraph direction, which was (0.034058467 0 0.0). In contrast, recall that with bidi-display-reordering at the default value t, the RTL test run was (5.249231941 1 0.014300497000000023), but now the LTR test run gave this: (10.613699099 1 0.012965359999999981) Again, the only difference between the buffers is the order of the strings and, consequently, the base paragraph direction. Both buffers consist of 800 copies of the strings and in both point-max is 16001. The -- in view of your below explanation -- unexpectedly large timing for the LTR buffer reminded me of the file in which I first encountered the slowdown, which consists of a number of Emacs Lisp sexps. The first group are all ASCII characters, so the base paragraph direction is LTR. Then there is a vector of 827 lists in a single line (remember, it's a generated file), each list containing three strings, one in Arabic script, one in English, one a transliteration of the Arabic which in many cases uses non-ASCII characters. The benchmark run for M-> in the buffer visiting this file was: (9.308704995000001 4 0.054923504999999984) The buffer size here is considerably larger than the buffers for my test runs; I couldn't remember it exactly, so I typed `M-: (point)' in the buffer, with the result 43901. It took a number of seconds for the result to be displayed, during which Emacs was unresponsive, so I then ran (benchmark-run nil (point)) in that buffer, with this result: (9.030000000000001e-07 0 0.0) I don't know what this result means, but the reported execution time bears no relation to actual elapsed time until the value of point was displayed. So I reran the benchmark and also manually timed it with a stopwatch. This is the result of the second benchmark: (3.1120000000000004e-06 0 0.0) However, the stopwatch showed fully 15 seconds. Maybe benchmark-run doesn't work for point for some reason. Given my doubts, I reran the benchmark on the test LTR buffer, but the reported execution time was only slightly different from before: (10.317616279000001 0 0.0) What do you make of these results? > 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. This sounds plausible, but my results seem to indicate there something else (or more) going on. > I will see if we can do better in this matter. I appreciate whatever you can do. Steve Berman