From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#15555: 24.3; Bidirectional display very slow with long lines Date: Tue, 18 Feb 2014 19:42:41 +0200 Message-ID: <838ut871wu.fsf@gnu.org> References: <83wqlo461e.fsf@gnu.org> <8338obskk4.fsf@gnu.org> <83iox6qt1t.fsf@gnu.org> <53035588.3080705@dev.rtsoft.ru> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1392746052 14644 80.91.229.3 (18 Feb 2014 17:54:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 18 Feb 2014 17:54:12 +0000 (UTC) Cc: 15555@debbugs.gnu.org To: Dmitry Antipov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Feb 18 18:54:20 2014 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WFos6-0003ZS-D9 for geb-bug-gnu-emacs@m.gmane.org; Tue, 18 Feb 2014 18:54:18 +0100 Original-Received: from localhost ([::1]:52422 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WFos6-0004eS-1Y for geb-bug-gnu-emacs@m.gmane.org; Tue, 18 Feb 2014 12:54:18 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51124) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WForw-0004bY-1m for bug-gnu-emacs@gnu.org; Tue, 18 Feb 2014 12:54:13 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WForp-0004OZ-K3 for bug-gnu-emacs@gnu.org; Tue, 18 Feb 2014 12:54:08 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:57576) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WForp-0004Ny-GF for bug-gnu-emacs@gnu.org; Tue, 18 Feb 2014 12:54:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1WFohB-0006ic-MM for bug-gnu-emacs@gnu.org; Tue, 18 Feb 2014 12:43:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 18 Feb 2014 17:43:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15555 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 15555-submit@debbugs.gnu.org id=B15555.139274536425798 (code B ref 15555); Tue, 18 Feb 2014 17:43:01 +0000 Original-Received: (at 15555) by debbugs.gnu.org; 18 Feb 2014 17:42:44 +0000 Original-Received: from localhost ([127.0.0.1]:58746 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WFogu-0006hz-1P for submit@debbugs.gnu.org; Tue, 18 Feb 2014 12:42:44 -0500 Original-Received: from mtaout24.012.net.il ([80.179.55.180]:47887) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WFogq-0006hb-4k for 15555@debbugs.gnu.org; Tue, 18 Feb 2014 12:42:42 -0500 Original-Received: from conversion-daemon.mtaout24.012.net.il by mtaout24.012.net.il (HyperSendmail v2007.08) id <0N1700700D2BT300@mtaout24.012.net.il> for 15555@debbugs.gnu.org; Tue, 18 Feb 2014 19:41:21 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout24.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N17004V3D4W5G00@mtaout24.012.net.il>; Tue, 18 Feb 2014 19:41:20 +0200 (IST) In-reply-to: <53035588.3080705@dev.rtsoft.ru> X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.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-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:85836 Archived-At: > Date: Tue, 18 Feb 2014 16:43:52 +0400 > From: Dmitry Antipov > CC: 15555@debbugs.gnu.org > > Hm... I have two files, with 2000 and 4000 first chars extracted from the beginning > of the monster string from http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15555#5. > > The following function: > > (defun bug15555 () > (interactive) > (while (not (eobp)) > (right-char 1) > (redisplay) > (sleep-for 0.01))) > > runs smoothly over 2000.txt, but painfully slow over 4000.txt. I'm not sure I can reproduce this. Is it possible that the difference you see between the speed of moving the cursor in these the two files is due solely to the fact that the smaller file fits completely in the window, while the larger file does not? IOW, if you enlarge the window such that the larger file is visible in its entirety, don't you see the same speed as with the smaller file? (I need about 52 lines of text in the window to show the whole of the file 4000.txt.) Likewise if you insert a R2L character at the beginning of 4000.txt, thus making its paragraph take the R2L base direction: now the cursor motion is fast even if the display needs to scroll to keep point visible, i.e. with the original window size you get in "emacs -Q". Also, the cursor movement is quite fast, and uses about 8% of a single execution unit of my Core i7, until the first time it needs to go outside the visible portion of the buffer, at which point the CPU usage of that single execution unit soars to almost 80%. If you see something different, please describe what you see. If you see what I described above, then this is a known (to me ;-) problem: when we have a continued line that takes more than 2 screen lines, and that line consists of mostly R2L characters, but the paragraph direction is L2R (or vice versa), then redisplay sometimes infloops when it needs to scroll the text in the window. The loop is not on the C level, it just causes a continuous series of re-entering redisplay, so you can stop this "infloop" by some radical cursor motion command, like C-v. This problem is hard to solve, because the code which finds a suitable window-start intrinsically assumes that the window-start position is always at column zero of the window, which is false with bidirectional text. Some of the code that is related to this needs to be redesigned to avoid this assumption. I hope to get to this some day, but since this situation is quite rare (paragraphs full of R2L characters normally have R2L base direction), this problem was never high on my todo list. > The latter case also shows the very pathological profile with ~25% > CPU spent in memcpy. > > Are you sure that bidi_copy_it doesn't add one more bottleneck to the whole > stuff? No, I don't think it does. But doing that in an infloop might ;-) Anyway, just moving cursor horizontally cannot possibly be slow due to bidi, especially as long as point stays in the same screenful. The redisplay becomes unbearably slow with long lines only when you either scroll the display (e.g., C-v) or for vertical cursor motion, because these require the display engine to traverse many buffer positions, many more than is needed to just move the cursor, and it currently can only start that traversal from the beginning of a physical line.