From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#56682: Fix the long lines font locking related slowdowns Date: Fri, 05 Aug 2022 14:40:35 +0300 Message-ID: <835yj62a18.fsf@gnu.org> References: <49df74e5-e16a-a532-98d1-66c6ff1eb6c6@yandex.ru> <83pmhuft5a.fsf@gnu.org> <05388e8d8836c2e7ef3e@heytings.org> <136c4fe0fcb9ce5181cb@heytings.org> <3d639ea12689d767ba2a@heytings.org> <838ro44fc8.fsf@gnu.org> <3d639ea126d759bddfea@heytings.org> <83y1w42vp4.fsf@gnu.org> <3d639ea12618e6a503af@heytings.org> <83wnbo2uw3.fsf@gnu.org> <3d639ea126e3a4d880b8@heytings.org> <83k07o2izh.fsf@gnu.org> <3d639ea1265c40a07f40@heytings.org> <83h72s2e3o.fsf@gnu.org> <3d639ea126c6b0c6737b@heytings.org> <838ro42b1g.fsf@gnu.org> <3d639ea126db3913202e@heytings.org> <83wnbn264f.fsf@gnu.org> <3d639ea12684115449f8@heytings.org> <83tu6r1b03.fsf@gnu.org> <92da07bd02b96d54dbf4@heytings.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="35534"; mail-complaints-to="usenet@ciao.gmane.io" Cc: gerd.moellmann@gmail.com, 56682@debbugs.gnu.org, monnier@iro.umontreal.ca, dgutov@yandex.ru To: Gregory Heytings Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Aug 05 13:41:46 2022 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 1oJvi5-000961-RI for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 05 Aug 2022 13:41:46 +0200 Original-Received: from localhost ([::1]:45918 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oJvi4-00054r-KO for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 05 Aug 2022 07:41:44 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40680) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oJvhO-00054C-CL for bug-gnu-emacs@gnu.org; Fri, 05 Aug 2022 07:41:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:38408) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oJvhO-00060N-3n for bug-gnu-emacs@gnu.org; Fri, 05 Aug 2022 07:41:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oJvhN-0004wi-V3 for bug-gnu-emacs@gnu.org; Fri, 05 Aug 2022 07:41:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 05 Aug 2022 11:41:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 56682 X-GNU-PR-Package: emacs Original-Received: via spool by 56682-submit@debbugs.gnu.org id=B56682.165969964818983 (code B ref 56682); Fri, 05 Aug 2022 11:41:01 +0000 Original-Received: (at 56682) by debbugs.gnu.org; 5 Aug 2022 11:40:48 +0000 Original-Received: from localhost ([127.0.0.1]:56390 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oJvhA-0004w7-8O for submit@debbugs.gnu.org; Fri, 05 Aug 2022 07:40:48 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:55892) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oJvh5-0004vd-FA for 56682@debbugs.gnu.org; Fri, 05 Aug 2022 07:40:46 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:53972) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oJvgy-0005rG-Vq; Fri, 05 Aug 2022 07:40:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=eozBLuudbMxvTf5roZ4W7e+IghaDps9YmtoAIr1KA/A=; b=PvW1nJ12Dx9v pbmih+R0P/q2CCLZ4NClXQuXfiAtAKD9kWOxeiY6KqY2Q3cMf5yUcnEZyrQJE1hYvcWiG0rRwd1gf emJt1PcmXnZZmS+PFm1rCGgXX4uz1SQvtg0hT9sx3T0B3LvE2TNtl3vshotDt98tM0Hv7jUQXY5sF Layp5xA74oImbETGzq4RxI94otJVuF6+9ejIcA3RyzqeSs3KKrzhm7enSjeEdMAODs8DLi3sB13aG mncOv8/QBoBG26Kg/rsvvqAFlsH/48iBSwUxxJY5UBEce59pYK/81gKnFMQNMxRpEQMS8F9l8hpRj 4KCWBY0tEEr9lHs0CeUOzw==; Original-Received: from [87.69.77.57] (port=4277 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oJvgy-0005M5-2K; Fri, 05 Aug 2022 07:40:36 -0400 In-Reply-To: <92da07bd02b96d54dbf4@heytings.org> (message from Gregory Heytings on Fri, 05 Aug 2022 09:37:35 +0000) 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" Xref: news.gmane.io gmane.emacs.bugs:238863 Archived-At: > Date: Fri, 05 Aug 2022 09:37:35 +0000 > From: Gregory Heytings > cc: gerd.moellmann@gmail.com, 56682@debbugs.gnu.org, monnier@iro.umontreal.ca, > dgutov@yandex.ru > > > It doesn't surprise me. If you disable font-lock and show-paren-mode, > > does it become significantly faster? And how does disabling font-lock > > that measure vs disabling auto-composition-mode with that file? > > Disabling show-paren-mode and font-lock has no effect, no. What is > surprising is that the speed seems to depend both on the mode and on the > presence of bidirectionality (so it seems that after all bidi is involved > in one way or another). That the presence of R2L characters makes this slower shouldn't surprise. The bidi iteration through buffer text _can_ be non-linear, but it's only _actually_ non-linear when R2L characters are present. So the complications with handle_stop_backwards and compute_stop_backwards actually happen only when there are R2L characters in the buffer; otherwise the iterator behaves exactly like the unidirectional display in Emacs 23 and before did: it examines characters one by one it strict increasing order of buffer positions, and skips or shortcuts some processing that is only needed for truly bidirectional text. IOW, the display engine is specially optimized for the very frequent case of buffers that don't include R2L characters, and is expected to be slower otherwise. If font-lock doesn't produce any tangible difference, it probably means that the amount of stop-positions added due to faces is negligible when compared to the stop-positions due to character composition. Which I guess is also reasonable with a script like Arabic. > 1. https://www.heytings.org/data/arabic-large.json > 2. https://www.heytings.org/data/arabic-large.json.txt > 3. https://www.heytings.org/data/arabic-large.txt > 4. https://www.heytings.org/data/arabic-large.txt.json > 5. https://www.heytings.org/data/arabic-small.json > 6. https://www.heytings.org/data/arabic-small.json.txt > 7. https://www.heytings.org/data/arabic-small.txt > 8. https://www.heytings.org/data/arabic-small.txt.json > > 1 and 2, 3 and 4, 5 and 6, 7 and 8 are the same file, the only difference > is the added extension. 1, 2, 3 and 4 on the one hand, and 5, 6, 7 and 8 > on the other hand, are almost the same file, the only difference is that > in 1 and 2 and 5 and 6 the arabic text is enclosed into '{"ar":" text>"}'. > > Now what you'll see is that 5 is slow, 6 is also slow (so it's not only > js-mode which is doing something wrong), 7 is fast, and 8 is again slow > (so js-mode is perhaps doing something wrong). Also, the motion commands > C-n and C-p do not work as expected in 5, 6 and 8. Thanks, I will use these. There's (at least) one more aspect of this, as long as Text mode is being used: Text mode doesn't force bidi-paragraph-direction to be left-to-right, whereas all descendants of prog-mode, including js-mode, do. Leaving bidi-paragraph-direction at nil means Emacs needs to determine the base paragraph direction each time it's about to redisplay a window, and that might be expensive, especially in a large buffer without any paragraph breaks (by default, an empty line), because that is determined by the first strong directional character of the paragraph. So for a more fair comparison with Text mode, you should set bidi-paragraph-direction to the value left-to-right in text-mode buffers.