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

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

[Ivan Shmakov]

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

>>>>> Eli Zaretskii <eliz@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

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

[Eli Zaretskii]

> From: Ivan Shmakov <ivan@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?

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

[Ivan Shmakov]

[-- Attachment #1: Type: text/plain, Size: 1474 bytes --]

>>>>> Eli Zaretskii <eliz@gnu.org> writes:
>>>>> From: Ivan Shmakov <ivan@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

[-- Attachment #2: Type: text/mediawiki, Size: 981 bytes --]

{{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.

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

[Eli Zaretskii]

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

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

[Ivan Shmakov]

>>>>> Eli Zaretskii <eliz@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

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

[Ivan Shmakov]

>>>>> Eli Zaretskii <eliz@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