Last Comment Bug 687861 - Horizontal scrolling in Orion with very long lines is slow
: Horizontal scrolling in Orion with very long lines is slow
: 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
: J. Ryan Stinnett [:jryans] (use ni?)
Depends on: 702331
  Show dependency treegraph
Reported: 2011-09-20 08:45 PDT by :Ehsan Akhgari
Modified: 2011-12-15 04:49 PST (History)
5 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Description User image :Ehsan Akhgari 2011-09-20 08:45:13 PDT

1. Go to <>, select all, copy.
2. Go to scratchpad, select all, paste.
3. Scroll horizontally.
4. Now go to data:text/html,<textarea rows=10 cols=80 wrap=off>, paste.
5. Scroll horizontally.

The scrolling in textarea is very smooth, the scrolling in scratchpad is slow and choppy.
Comment 1 User image Boris Zbarsky [:bz] (still a bit busy) 2011-09-20 10:34:58 PDT
I profiled this on Mac.  Specifically, I held my mouse down on the right scroll arrow and then started the profiler, waited a bit, and stopped it, using keyboard shortcuts (Option+esc).

The short of it is that 84% of the time is under reflow triggered from getBoundingClientRect calls coming off a scroll event.

I have no idea what the heck Orion is doing from horizontal scroll events, but it may want to stop doing it.  Looking at the profile, it includes at least lots of calls to getBoundingClentRect interspersed with .length gets on textnodes, .firstChild and .nextSibling gets on nodes, CSS property setting, CSS property getting, .scrollLeft gets, .style gets, createDocumentFragment calls (!), .clientHeight gets, .rows gets on tables, .selection gets on windows, .clientWidth gets, .scrollTop gets, .scrollWidth gets, .cells gets on table rows, .documentElement gets, .previousSibling gets, .style.height sets, etc, etc, etc.

The combination of style changes and reflow flushes is presumably what really kills performance here.  Why is Orion doing that, exactly?
Comment 2 User image Kevin Dangoor 2011-09-21 12:48:00 PDT
This is the upstream bug:
Comment 3 User image Boris Zbarsky [:bz] (still a bit busy) 2011-09-21 13:22:29 PDT
That upstream bug is about a hang loading a file with a really really long line in the editor.

We need separate upstream bugs to track this and bug 687865, I think.
Comment 4 User image Kevin Dangoor 2011-09-22 10:08:31 PDT
(In reply to Boris Zbarsky (:bz) from comment #3)
> That upstream bug is about a hang loading a file with a really really long
> line in the editor.

I put them together thinking that there may be one solution on their end and they can break it up based on the implementation.

But, I think your suggestion to break up the bug is better for ensuring that separate issues don't get lost.

New additional upstream bug:
Comment 5 User image Dave Camp (:dcamp) 2011-10-27 09:03:22 PDT
We're doing developer tool prioritization, filter on 'brontozaur'
to ignore the spam.
Comment 6 User image Mihai Sucan [:msucan] 2011-12-15 04:49:04 PST
This bug is now fixed upstream and the code has been integrated, see bug 702331.

If there are other or similar performance issues, please file separate bug reports. Thank you!

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