From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Jerome L Quinn Newsgroups: gmane.emacs.bugs Subject: bug#15555: 24.3; Bidirectional display very slow with long lines Date: Tue, 8 Oct 2013 11:39:58 -0400 Message-ID: References: <83wqlo461e.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; Boundary="0__=0ABBF16DDFC0A51D8f9e8a93df938690918c0ABBF16DDFC0A51D" X-Trace: ger.gmane.org 1381246884 15115 80.91.229.3 (8 Oct 2013 15:41:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 8 Oct 2013 15:41:24 +0000 (UTC) Cc: 15555@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Oct 08 17:41:27 2013 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 1VTZPV-0002B0-PK for geb-bug-gnu-emacs@m.gmane.org; Tue, 08 Oct 2013 17:41:21 +0200 Original-Received: from localhost ([::1]:37532 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VTZPV-0004eX-6o for geb-bug-gnu-emacs@m.gmane.org; Tue, 08 Oct 2013 11:41:21 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57357) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VTZPK-0004e8-Cy for bug-gnu-emacs@gnu.org; Tue, 08 Oct 2013 11:41:18 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VTZPC-0005da-Fr for bug-gnu-emacs@gnu.org; Tue, 08 Oct 2013 11:41:10 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:55024) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VTZPC-0005co-C3 for bug-gnu-emacs@gnu.org; Tue, 08 Oct 2013 11:41:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1VTZPB-0008Ss-SC for bug-gnu-emacs@gnu.org; Tue, 08 Oct 2013 11:41:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Jerome L Quinn Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 08 Oct 2013 15:41: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.138124680832472 (code B ref 15555); Tue, 08 Oct 2013 15:41:01 +0000 Original-Received: (at 15555) by debbugs.gnu.org; 8 Oct 2013 15:40:08 +0000 Original-Received: from localhost ([127.0.0.1]:35083 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VTZOI-0008Rf-Qf for submit@debbugs.gnu.org; Tue, 08 Oct 2013 11:40:07 -0400 Original-Received: from e9.ny.us.ibm.com ([32.97.182.139]:41087) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VTZOD-0008R7-G1 for 15555@debbugs.gnu.org; Tue, 08 Oct 2013 11:40:02 -0400 Original-Received: from /spool/local by e9.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for <15555@debbugs.gnu.org> from ; Tue, 8 Oct 2013 11:40:00 -0400 Original-Received: from d01dlp02.pok.ibm.com (9.56.250.167) by e9.ny.us.ibm.com (192.168.1.109) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Tue, 8 Oct 2013 11:40:00 -0400 Original-Received: from b01cxnp23032.gho.pok.ibm.com (b01cxnp23032.gho.pok.ibm.com [9.57.198.27]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id 8380E6E803F for <15555@debbugs.gnu.org>; Tue, 8 Oct 2013 11:39:58 -0400 (EDT) Original-Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by b01cxnp23032.gho.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r98FdxEt51183774 for <15555@debbugs.gnu.org>; Tue, 8 Oct 2013 15:39:59 GMT Original-Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r98Fdxtj023411 for <15555@debbugs.gnu.org>; Tue, 8 Oct 2013 11:39:59 -0400 Original-Received: from d01ml605.pok.ibm.com (d01ml605.pok.ibm.com [9.63.8.148]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id r98FdxNN023406; Tue, 8 Oct 2013 11:39:59 -0400 In-Reply-To: <83wqlo461e.fsf@gnu.org> X-KeepSent: 2B55B1F5:54EA9C4F-85257BFE:0053238D; type=4; name=$KeepSent X-Mailer: IBM Notes Release 9.0 March 08, 2013 X-MIMETrack: Serialize by Router on D01ML605/01/M/IBM(Release 9.0IF2 |July 03, 2013) at 10/08/2013 11:39:59 AM Content-Disposition: inline X-TM-AS-MML: No X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13100815-7182-0000-0000-000008AA68C2 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:79036 Archived-At: --0__=0ABBF16DDFC0A51D8f9e8a93df938690918c0ABBF16DDFC0A51D Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable Eli Zaretskii wrote on 10/08/2013 02:42:53 AM: > From: Eli Zaretskii > To: Jerome L Quinn/Watson/IBM@IBMUS > Cc: 15555@debbugs.gnu.org > Date: 10/08/2013 02:43 AM > Subject: Re: bug#15555: 24.3; Bidirectional display very slow with lo= ng lines > > > From: Jerome L Quinn > > Date: Mon, 7 Oct 2013 16:05:42 -0400 > > > > If I have a buffer with a very long line (14000 chars) with a mix o= f > > ASCII and Arabic text, emacs gets painfully slow when point is furt= her > > along the line. > > Emacs is in general painfully slow with such long lines, even if ther= e > are only ASCII characters there. Presence of Arabic characters makes= > it slower, but it is unbearably slow even before that. This is a > known deficiency of the Emacs display engine. This is bug #13675. Hi Eli, I'm not sure it is the same bug. When I disable the bidi reordering variable, navigation speed becomes reasonable, even with the very long line lengt= h. I'm on a very fast machine, so #13675 may not be impacting me that badl= y. When bidi reordering is enabled, it is multiple seconds to move the cur= sor up and down, which is unusable. > > It looks like there's an N^2 algorithm dependent on the column of > > point. > > No, there are no N=B2 algorithms. However, for many display operatio= ns, > Emacs needs to go to the beginning of the previous _physical_ line, > and then go forward to the place it needs to redisplay. With very > long lines, this takes a lot of time. > > If your data files don't include empty lines, there's perhaps another= > source of slowdown, which _is_ peculiar to bidirectional display: > Emacs needs to find the beginning of the current paragraph to > determine its "base direction". To see if this is your problem, try > setting bidi-paragraph-direction to either left-to-right or > right-to-left, depending on whether most of the text should be read > left to right or right to left. Setting bidi-paragraph-direction to right-to-left improves the situatio= n some but I'd still call it unusable in this situation. Disabling reordering= makes emacs as responsive as I'd expect, comparable to emacs23. OK, I played with it a bit more. I think the issue is exacerbated by splitting the frame into 2 side-by-side windows. Try this: Expand emacs to fill the screen. For me this is 194x65. Create a new buffer with just the text I included in the bug report. C-x 3 Put something else in the left window and go the right window. Page down several times. The last page down I find takes 5-8 seconds repeatedly. I don't see as bad behavior when the text is in the left buffer or if I= have only 1 window. And disabling bidi reordering completely eliminates the bad behavior. Thanks Jerry= --0__=0ABBF16DDFC0A51D8f9e8a93df938690918c0ABBF16DDFC0A51D Content-type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-transfer-encoding: quoted-printable

Eli Zaretskii <eliz@gnu.org> wrote on 10/= 08/2013 02:42:53 AM:

> From: Eli Zaretskii <eliz@gnu.org>
> To: Jerome L Quinn/Watson/IBM@IBMUS
> Cc: 15555@debbugs.gnu.org
> Date: 10/08/2013 02:43 AM
> Subject: Re: bug#15555: 24.3; Bidirectional d= isplay very slow with long lines
>
> > From: Jerome L Quinn <jlquinn@us.ibm.com>
> > Date: Mon, 7 Oct 2013 16:05:42 -0400
> >
> > If I have a buffer with a very long line (14000 chars) with a= mix of
> > ASCII and Arabic text, emacs gets painfully slow when point i= s further
> > along the line.
>
> Emacs is in general painfully slow with such long lines, even if t= here
> are only ASCII characters there.  Presence of Arabic characte= rs makes
> it slower, but it is unbearably slow even before that.  This = is a
> known deficiency of the Emacs display engine.  This is bug #1= 3675.

Hi Eli,

I'm not sure it is the same bug.  When I disa= ble the bidi reordering variable,
navigation speed becomes reasonable, even with the= very long line length.
I'm on a very fast machine, so #13675 may not be i= mpacting me that badly.

When bidi reordering is enabled, it is multiple se= conds to move the cursor up
and down, which is unusable.


> > It looks like there's an N^2 algorithm dependent on the colum= n of
> > point.
>
> No, there are no N=B2 algorithms.  However, for many display = operations,
> Emacs needs to go to the beginning of the previous _physical_ line= ,
> and then go forward to the place it needs to redisplay.  With= very
> long lines, this takes a lot of time.
>
> If your data files don't include empty lines, there's perhaps anot= her
> source of slowdown, which _is_ peculiar to bidirectional display:<= br> > Emacs needs to find the beginning of the current paragraph to
> determine its "base direction".  To see if this is = your problem, try
> setting bidi-paragraph-direction to either left-to-right or
> right-to-left, depending on whether most of the text should be rea= d
> left to right or right to left.

Setting bidi-paragraph-direction to right-to-left = improves the situation some
but I'd still call it unusable in this situation. =  Disabling reordering makes
emacs as responsive as I'd expect, comparable to e= macs23.

OK, I played with it a bit more.  I think the= issue is exacerbated by splitting
the frame into 2 side-by-side windows.=

Try this:

Expand emacs to fill the screen.  For me this= is 194x65.
Create a new buffer with just the text I included = in the bug report.
C-x 3
Put something else in the left window and go the r= ight window.
Page down several times.

The last page down I find takes 5-8 seconds repeat= edly.

I don't see as bad behavior when the text is in th= e left buffer or if I have only
1 window.

And disabling bidi reordering completely eliminate= s the bad behavior.


Thanks
Jerry
= --0__=0ABBF16DDFC0A51D8f9e8a93df938690918c0ABBF16DDFC0A51D--