(no longer active) Reporter
	Description • 13 years ago

STR:

1. Go to <https://bugzilla.mozilla.org/js/yui/yahoo-dom-event/yahoo-dom-event.js?1303753510>, select all, copy.
2. Go to scratchpad, select all, paste.
3. Put the caret on the middle of a long line, press Enter.
4. Now go to data:text/html,<textarea rows=10 cols=80 wrap=off>, paste.
5. Put the caret on the middle of a long line, press Enter.

In step 3, there is a visible delay between pressing enter, the rest of the line being moved to a new line, horizontal scrolling, and the caret showing up.  In step 5, all of that is instant.

	Boris Zbarsky [:bzbarsky]
	Comment 1 • 13 years ago

In a textarea, all we have to do for this operation is insert the linebreak in the textnode and then reflow the text as needed.  And we optimize it pretty heavily.

Orion ends up having to either move nodes from one <div> into another or just delete nodes and create new ones.   It seems to have chosen to do the latter.  A profile shows 3-4% spent creating new elements, 5% inserting them into the DOM (includes eager frame construction, since this is editable content), 3% creating text noes, 2% adding them to elements, 12% layout flushes after doing all that.  All of that is under a setTimeout call.

Then on a _separate_ keydown event dispatch, 45% layout flushes, 5% more element insertion, 3% more element creation, 2% more text node creation, 2% removeChild, etc, etc.

So it looks like on keydown orion does a bunch of work including layout flushes (why????) and then sets a timeout to do even more work, including _separate_ layout flushes.

And it also looks like it's modifying large live editable DOMs by adding/removing nodes, which triggers eager form construction.

It's like a textbook example of how to work around layout engine optimizations.  ;)

	Kevin Dangoor
	Comment 2 • 13 years ago

I've added a comment for the upstream bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=354435

I'll leave it to them to decide if they want to split long line support into more than one bug (we have another bug 687861 for long line scrolling)

	Kevin Dangoor
	Comment 3 • 13 years ago

At bz's suggestion, I have filed this as a separate upstream bug:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=358645

	Dave Camp (:dcamp)
	Comment 4 • 13 years ago

We're doing developer tool prioritization, filter on 'brontozaur'
to ignore the spam.

	Mihai Sucan [:msucan]
	Comment 5 • 13 years ago

The STR provided here is no longer slow on my machine. This STR and other performance issues related to changes happening in very long lines have been fixed upstream. The code has been integrated into the Firefox codebase, see bug 702331.

Please file separate bug reports if you still encounter similar performance issues. Thank you!