Last Comment Bug 687861 - Horizontal scrolling in Orion with very long lines is slow
: Horizontal scrolling 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:45 PDT by :Ehsan Akhgari
Modified: 2011-12-15 04:49 PST (History)
5 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description :Ehsan Akhgari 2011-09-20 08:45:13 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. 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 Boris Zbarsky [:bz] 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 Kevin Dangoor 2011-09-21 12:48:00 PDT
This is the upstream bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=354435
Comment 3 Boris Zbarsky [:bz] 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 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:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=358628
Comment 5 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 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.