Last Comment Bug 846128 - SimileTimeline extremely slow in firefox
: SimileTimeline extremely slow in firefox
Status: NEW
: perf
Product: Core
Classification: Components
Component: Layout: View Rendering (show other bugs)
: unspecified
: x86_64 Windows 7
: -- major with 1 vote (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
http://www.janbambas.cz/moz/profiler/...
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-02-27 18:39 PST by Honza Bambas (:mayhemer)
Modified: 2013-08-05 02:52 PDT (History)
8 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Honza Bambas (:mayhemer) 2013-02-27 18:39:16 PST
Reporting as a general issue, since native code and JS code profiling doesn't tell me where the problem exactly is.

STR:
- go to http://www.janbambas.cz/moz/profiler/?logs/vodafone-long-load-no-keep-alive.txt
- grab the timeline anywhere and drag to left or right to move it
- scrolling is extremely abrupt

Compare to how Chrome behaves with the same URL - perfectly fluent!


This is good use case that can be used to find weak places in JS/rendering code.  This is a major issue and clearly the timeline rendering can be fluent as Chrome shows.  We must do something to make this much much better.


What more can I do to try to find the bottleneck?
Comment 1 Honza Bambas (:mayhemer) 2013-02-27 18:41:28 PST
Same when comparing on an old and slow imac using Safari - perfectly fluent.
Comment 2 Boris Zbarsky [:bz] 2013-02-27 20:23:07 PST
I assume you've made sure this script is not doing browser-sniffing like seems to be the vogue today? ;)

Assuming that, here's what my profiler says when I drag around a bunch:

52% reflow triggered by scripted offsetHeight gets off an event of some sort.
 9% restyling triggered similarly
20% painting off the refresh driver

The rest is noise.

Note that we fire mouse move events a lot more often than WebKit does, so if each event handler takes too long we could end up starving paints.  Have you tried roc's proposed patches to do mouse moves off the refresh driver?
Comment 3 Honza Bambas (:mayhemer) 2013-02-28 08:34:13 PST
(In reply to Boris Zbarsky (:bz) from comment #2)
> I assume you've made sure this script is not doing browser-sniffing like
> seems to be the vogue today? ;)

Just to say by true "no": overriding user agent to UA of chrome - no change :)

> 
> Assuming that, here's what my profiler says when I drag around a bunch:
> 
> 52% reflow triggered by scripted offsetHeight gets off an event of some sort.
>  9% restyling triggered similarly
> 20% painting off the refresh driver
> 
> The rest is noise.
> 
> Note that we fire mouse move events a lot more often than WebKit does, so if
> each event handler takes too long we could end up starving paints.  Have you
> tried roc's proposed patches to do mouse moves off the refresh driver?

I'll check and report.  Can you please direct me to the patches?  Can't find it..
Comment 4 Boris Zbarsky [:bz] 2013-02-28 08:39:59 PST
Hmm.  I thought they were around, but can't find them... roc, was it just discussion so far?

Note that for this case we really do want the throttling, not just anti-flooding.
Comment 5 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2013-02-28 15:22:47 PST
Yes, I haven't done it yet. Why do you you think we need throttling, not just anti-flooding?
Comment 6 Boris Zbarsky [:bz] 2013-02-28 15:35:50 PST
Hmm.  I guess it depends on exactly what's happening here.  If just anti-flooding would end up with us repainting on time, great.

Note that I was seeing performance issues here on Mac, not on Windows where we had the flooding issues...
Comment 7 Honza Bambas (:mayhemer) 2013-03-01 09:06:23 PST
In general, Simile Timeline on few places in time has to restructure the events displayed on screen, this causes a short jank in all browsers (however, in Firefox longer then in Chrome).  

When you scroll just a little piece back and forth on place in time where this restructure doesn't happen, it's fluent otherwise.  In detail:

Win (7 x64), fast native machine:
  Firefox: very abrupt       
  Chrome: very fluent

iMac (10.7 x86), old and slow:
  Firefox: abrupt, but a little bit less then on Win
  Chrome: very fluent
  Safari: very fluent

Fedora (17 x64), old and slow single core machine, view port via VNC (!), local net, SSH tunneled
  Firefox: very much abrupt       
  Chrome: very (or say, very reasonably) fluent


This really is not Windows specific.
Comment 8 Honza Bambas (:mayhemer) 2013-03-01 09:14:28 PST
One hint: when I grab the timeline and quickly move mouse in a small range left and right (like shaking), in Firefox the timeline almost doesn't response.  When I release the mouse on some other place then I've grabbed the timeline originally then it (subjectively) instantly redraws at the expected position.  Tested on all platforms.

During the "shaking" CPU user time is at 100%, kernel insignificant (nearly 0%).  CPU tested only in Win.
Comment 9 Honza Bambas (:mayhemer) 2013-03-08 07:39:24 PST
So, any news here?

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