Last Comment Bug 687865 - Line insertion in Orion with very long lines is slow
: Line insertion in Orion with very long lines is slow
Status: RESOLVED FIXED
[sourceeditor][orion]
: perf
Product: Firefox
Classification: Client Software
Component: Developer Tools (show other bugs)
: Trunk
: All All
: P2 normal (vote)
: Firefox 11
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
Depends on: 702331
Blocks:
  Show dependency treegraph
 
Reported: 2011-09-20 08:48 PDT by :Ehsan Akhgari (away Aug 1-5)
Modified: 2011-12-15 04:53 PST (History)
5 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description :Ehsan Akhgari (away Aug 1-5) 2011-09-20 08:48:07 PDT
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.
Comment 1 Boris Zbarsky [:bz] 2011-09-20 10:50:29 PDT
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.  ;)
Comment 2 Kevin Dangoor 2011-09-21 12:53:53 PDT
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)
Comment 3 Kevin Dangoor 2011-09-22 11:25:30 PDT
At bz's suggestion, I have filed this as a separate upstream bug:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=358645
Comment 4 Dave Camp (:dcamp) 2011-10-27 09:03:24 PDT
We're doing developer tool prioritization, filter on 'brontozaur'
to ignore the spam.
Comment 5 Mihai Sucan [:msucan] 2011-12-15 04:53:51 PST
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!

Note You need to log in before you can comment on or make changes to this bug.