Line insertion in Orion with very long lines is slow

RESOLVED FIXED in Firefox 11



Developer Tools
6 years ago
6 years ago


(Reporter: Ehsan, Unassigned)



Firefox 11

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [sourceeditor][orion])


1. Go to <>, 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.
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

6 years ago
I've added a comment for the upstream bug:

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

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


6 years ago
Summary: Line insertion in scratchpad with very long lines is slow → Line insertion in Orion with very long lines is slow
Whiteboard: [sourceeditor][orion]

Comment 4

6 years ago
We're doing developer tool prioritization, filter on 'brontozaur'
to ignore the spam.
Priority: -- → P2


6 years ago
Depends on: 702331
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!
Last Resolved: 6 years ago
OS: Mac OS X → All
Hardware: x86 → All
Resolution: --- → FIXED
Target Milestone: --- → Firefox 11
You need to log in before you can comment on or make changes to this bug.