GNU bug report logs - #18778
noticeable slowdown for buffers with long lines, word-wrap, and brackets

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 18778 in the body.
You can then email your comments to 18778 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Ivan Shmakov <ivan <at> siamics.net>
To: submit <at> debbugs.gnu.org
Subject: noticeable slowdown for buffers with long lines, word-wrap,
 and brackets 
Date: Mon, 20 Oct 2014 19:17:28 +0000

Package: emacs
X-Debbugs-Cc: Eli Zaretskii <eliz <at> gnu.org>

>>>>> Eli Zaretskii <eliz <at> gnu.org> writes:

[…]

 > In addition, one of the new UBA features, the so-called Bidirectional
 > Parentheses Algorithm (BPA), affects pure-ASCII text as well, and
 > specifically editing of program sources (which widely use parentheses
 > and brackets of several kinds).

 > The result is some small slowdown -- a few percents in my testing --
 > in redisplay operations.  If more significant slowdown will be
 > reported in some special cases, I will try to find optimizations to
 > countermand that.

	It seems that I’ve just found such a case for 13a3ad6b39c0.

	To reproduce:

	• create a buffer with long lines (see below for the example
	  I’ve used), and (setq word-wrap t line-move-visual nil) there;

	• now, enclose every line in [, ] brackets (as in: M-x
	  replace-regexp RET .* RET [\&] RET; parentheses or curly
	  braces also exhibit the issue.)

	For the resulting buffer, operations like (next-line) or even
	(recenter) now result in a noticeable delay.

	The issue doesn’t appear when word-wrap is not used, or when
	there’s no brackets in the buffer.  Neither the issue appears in
	Emacs built 2014-10-09 from a then-recent Git clone.

	I’ve used the output of the following Shell command as a test.

$ head -n 8192 < /usr/share/dict/american-english | fmt -w 1024 

[…]

-- 
FSF associate member #7257  http://boycottsystemd.org/  … 3013 B6A0 230E 334A

Message #8 received at 18778 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ivan Shmakov <ivan <at> siamics.net>
Cc: 18778 <at> debbugs.gnu.org
Subject: Re: bug#18778: noticeable slowdown for buffers with long lines,
 word-wrap, and brackets
Date: Mon, 20 Oct 2014 22:33:12 +0300

> From: Ivan Shmakov <ivan <at> siamics.net>
> Date: Mon, 20 Oct 2014 19:17:28 +0000
> 
> 	• create a buffer with long lines (see below for the example
> 	  I’ve used), and (setq word-wrap t line-move-visual nil) there;
> 
> 	• now, enclose every line in [, ] brackets (as in: M-x
> 	  replace-regexp RET .* RET [\&] RET; parentheses or curly
> 	  braces also exhibit the issue.)
> 
> 	For the resulting buffer, operations like (next-line) or even
> 	(recenter) now result in a noticeable delay.
> 
> 	The issue doesn’t appear when word-wrap is not used, or when
> 	there’s no brackets in the buffer.  Neither the issue appears in
> 	Emacs built 2014-10-09 from a then-recent Git clone.
> 
> 	I’ve used the output of the following Shell command as a test.
> 
> $ head -n 8192 < /usr/share/dict/american-english | fmt -w 1024 

Is it an important use case?  If so, what is the real-life situation
here?

Message #11 received at 18778 <at> debbugs.gnu.org (full text, mbox):

From: Ivan Shmakov <ivan <at> siamics.net>
To: 18778 <at> debbugs.gnu.org
Subject: Re: bug#18778: noticeable slowdown for buffers with long lines,
 word-wrap, and brackets
Date: Mon, 20 Oct 2014 19:51:29 +0000

[Message part 1 (text/plain, inline)]

>>>>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>>>> From: Ivan Shmakov <ivan <at> siamics.net>

[…]

 >> For the resulting buffer, operations like (next-line) or even
 >> (recenter) now result in a noticeable delay.

 >> The issue doesn’t appear when word-wrap is not used, or when there’s
 >> no brackets in the buffer.  Neither the issue appears in Emacs built
 >> 2014-10-09 from a then-recent Git clone.

 >> I’ve used the output of the following Shell command as a test.

 >> $ head -n 8192 < /usr/share/dict/american-english | fmt -w 1024

 > Is it an important use case?

	Is there any example of content for which using word-wrap would
	be reasonable, but which will never ever contain any braces?

 > If so, what is the real-life situation here?

	For one thing, MediaWiki (as in: Wikipedia) pages tend to use
	paragraph-long lines, and (just as any other human-readable text
	usually does) they use various braces more than occasionally;
	not to mention using [, ], {, } for the markup purposes.  (A few
	initial lines of the https://en.wikipedia.org/wiki/Emacs page
	source are MIMEd.)

	Using word-wrap when editing such pages is also more or less an
	obvious measure.

	(Now, for sure, I can try to mass-edit the pages I’m interested
	in to fit in 80 columns, but I doubt such a move would receive a
	warm welcome from the community.)

-- 
FSF associate member #7257  http://boycottsystemd.org/  … 3013 B6A0 230E 334A

[Message part 2 (text/mediawiki, inline)]

{{Distinguish|eMac}}
[[File:Emacs Dired buffers.png|thumb|Editing multiple [[Dired]] buffers in [[GNU Emacs]]]]

'''Emacs''' {{IPAc-en|ˈ|iː|m|æ|k|s}} and its derivatives are a family of [[text editor]]s that are characterized by their [[extensibility]]. The manual for the most widely-used variant, [[GNU Emacs]], describes it as "the extensible, customizable, self-documenting, real-time display editor".<ref>{{cite web|title=GNU Emacs Manual|url=https://www.gnu.org/software/emacs/manual/html_node/emacs/index.html|work=GNU Emacs Manual|publisher=FSF|accessdate=24 November 2012}}</ref>  Development of the first Emacs began in the mid-1970s and continues actively {{as of|2014|lc=on}}. Emacs has over 2,000 built-in commands and allows the user to combine these commands into [[macro (computer science)|macros]] to automate work. The use of [[Emacs Lisp]], a variant of the [[Lisp (programming language)|Lisp]] programming language, provides a deep extension capability.

Message #14 received at 18778 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ivan Shmakov <ivan <at> siamics.net>
Cc: 18778 <at> debbugs.gnu.org
Subject: Re: bug#18778: noticeable slowdown for buffers with long lines,
 word-wrap, and brackets
Date: Wed, 22 Oct 2014 19:12:02 +0300

In trunk revision 118179 I introduced an optimization that fixes these
situations.

Message #17 received at 18778 <at> debbugs.gnu.org (full text, mbox):

From: Ivan Shmakov <ivan <at> siamics.net>
To: 18778 <at> debbugs.gnu.org
Subject: Re: bug#18778: noticeable slowdown for buffers with long lines,
 word-wrap, and brackets 
Date: Wed, 22 Oct 2014 17:07:13 +0000

>>>>> Eli Zaretskii <eliz <at> gnu.org> writes:

 > In trunk revision 118179 I introduced an optimization that fixes
 > these situations.

	ACK, thanks.  (I don’t currently plan upgrading my Emacs
	instance before early next week, thus I won’t be able to test
	them myself until then either.)

-- 
FSF associate member #7257  http://boycottsystemd.org/  … 3013 B6A0 230E 334A

Message #22 received at 18778-done <at> debbugs.gnu.org (full text, mbox):

From: Ivan Shmakov <ivan <at> siamics.net>
To: 18778-done <at> debbugs.gnu.org
Subject: Re: bug#18778: noticeable slowdown for buffers with long lines,
 word-wrap, and brackets 
Date: Wed, 29 Oct 2014 19:31:59 +0000

>>>>> Eli Zaretskii <eliz <at> gnu.org> writes:

 > In trunk revision 118179 I introduced an optimization that fixes
 > these situations.

	As of 4fd1634dbdd8, I no longer observe this issue, thus closing
	this bug.

	Thanks again.

-- 
FSF associate member #7257  http://boycottsystemd.org/  … 3013 B6A0 230E 334A

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.