From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#30457: 26.0.91; bidi-display-reordering makes navigation around melpa/archive-contents slow Date: Thu, 15 Feb 2018 23:47:26 +0200 Message-ID: <83sha2udqp.fsf@gnu.org> References: <83tvujwh2t.fsf@gnu.org> <83mv0bwds5.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1518731207 3241 195.159.176.226 (15 Feb 2018 21:46:47 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 15 Feb 2018 21:46:47 +0000 (UTC) Cc: 30457@debbugs.gnu.org To: Aaron Jensen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Feb 15 22:46:43 2018 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1emRLy-0006uH-J5 for geb-bug-gnu-emacs@m.gmane.org; Thu, 15 Feb 2018 22:46:06 +0100 Original-Received: from localhost ([::1]:35084 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1emRO0-0002wJ-Fx for geb-bug-gnu-emacs@m.gmane.org; Thu, 15 Feb 2018 16:48:12 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51397) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1emRNt-0002w9-L4 for bug-gnu-emacs@gnu.org; Thu, 15 Feb 2018 16:48:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1emRNq-00069D-JK for bug-gnu-emacs@gnu.org; Thu, 15 Feb 2018 16:48:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:37308) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1emRNq-000699-F5 for bug-gnu-emacs@gnu.org; Thu, 15 Feb 2018 16:48:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1emRNq-0001w5-8D for bug-gnu-emacs@gnu.org; Thu, 15 Feb 2018 16:48:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 15 Feb 2018 21:48:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 30457 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 30457-submit@debbugs.gnu.org id=B30457.15187312637417 (code B ref 30457); Thu, 15 Feb 2018 21:48:02 +0000 Original-Received: (at 30457) by debbugs.gnu.org; 15 Feb 2018 21:47:43 +0000 Original-Received: from localhost ([127.0.0.1]:45205 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1emRNW-0001vZ-Qu for submit@debbugs.gnu.org; Thu, 15 Feb 2018 16:47:43 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:60342) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1emRNV-0001vM-6e for 30457@debbugs.gnu.org; Thu, 15 Feb 2018 16:47:41 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1emRNM-00061P-V1 for 30457@debbugs.gnu.org; Thu, 15 Feb 2018 16:47:36 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:39773) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1emRNM-00061J-Qw; Thu, 15 Feb 2018 16:47:32 -0500 Original-Received: from [176.228.60.248] (port=2603 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1emRNM-0004zk-8x; Thu, 15 Feb 2018 16:47:32 -0500 In-reply-to: (message from Aaron Jensen on Thu, 15 Feb 2018 10:49:23 -0800) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 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.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:143322 Archived-At: > From: Aaron Jensen > Date: Thu, 15 Feb 2018 10:49:23 -0800 > Cc: 30457@debbugs.gnu.org > > > It isn't WONTFIX, I just don't know how to make the BPA implementation > > faster with such long lines and deeply nested parentheses. It already > > includes all the optimizations I could think of. But maybe someone > > else will find a way to optimize it more. > > I'm only just now learning about BPA, so I apologize if this is a > silly question, but would it be any faster to scan a buffer and > determine that there are no rtl characters so parentheses matching is > unnecessary? Scanning the entire buffer could be faster only for small buffers. But with a very large buffer we'd be scanning a lot more than needed, because redisplay tries very hard not to examine much more of the buffer than is needed to show one window-full. And due to the way the display engine is designed, it doesn't lend itself easily to caching stuff, so you'd need to scan the entire buffer every redisplay cycle, e.g., after each C-n. The current code in bidi_find_bracket_pairs scans only as much as needed (which unfortunately could be quite a lot for deeply nested parens in a long line). And it already includes an optimization for strictly left-to-right text inside the parens, something that it detects as part of the scan. > > It does, sort of. At least near the end of the buffer you clearly see > > that bidi-display-reordering has a much smaller effect, in relative > > terms. > > Yeah, I wasn't aware that the end of the buffer had more slowness, but > that's good to know. The farther you are from the beginning of line, the more buffer positions Emacs needs to scan to determine where to put point after C-n or C-p. That's because the layout calculations needed for determining coordinates of each buffer position must start from some known anchor, and currently the only anchor is the line beginning, where we sure the X coordinate is zero. So Emacs needs to go back to the line beginning (something it can do very fast), and then come back (much slower) one character at a time, until it hits the buffer position with the right coordinate. That coming back is the main reason why doing this near the end of the line is so much slower than near the beginning.