Firefox/Features/50ms ASSERT: Difference between revisions

no edit summary
No edit summary
No edit summary
 
(23 intermediate revisions by 7 users not shown)
Line 1: Line 1:
<section begin="status" />
{{FeatureStatus
|Feature name=Primary UI Responsiveness - 50ms goal
|Feature stage=Complete
|Feature health=OK
|Feature status note=Core instrumentation landed, resulting in various tools built on top of it. Current work utilizing these tools is the [https://wiki.mozilla.org/Performance/Snappy Snappy] project. SDR: N SIR: N
}}
{{FeatureTeam
|Feature product manager=Asa Dotzler
|Feature feature manager=Dietrich Ayala
|Feature security lead=Curtis Koenig
|Feature qa lead=AndreiD
|Feature additional members=ted (infrastructure lead)
}}
{{FeaturePageBody
|Feature overview=Any time the user interface takes more than 50ms to respond to an action, the application will appear sluggish to the user. To determine how often this happens, and what parts of our code are frequent offenders, we should add the ability to detect when the main-thread event loop is delayed by more than 50ms and log it as an ASSERT.


{| class="fullwidth-table"
However, just an ASSERT does not tell developers *what caused* the delay. In order to be useful, we must provide the ability for developers to easily get information about what code is slow.
|-
| style="font-weight: bold; background: #DDD;" | Feature
| style="font-weight: bold; background: #DDD;" | Status
| style="font-weight: bold; background: #DDD;" | ETA
| style="font-weight: bold; background: #DDD;" | Owner
|-
| [[Firefox/Features/50ms_ASSERT|ASSERT when UI is delayed by more than 50ms]]
|
{{StatusHealthy|status=Core instrumentation landed}}&nbsp;<br>


| 2011-04-29
There are generally two scenarios in which the browser UI is non-responsive.
| [[User:Dietrich|dietrich]]
<section end="status" />


|}
# When a direct action by the user causes the app to be non-responsive. For example, a menu option that executes an action synchronously, and takes >50ms to return.
# When a background action blocks the event loop for >50ms, causing the whole app to be non-responsive.


== Summary  ==
The goal of this project is to get developer visibility into both scenarios with easy-to-use tools.


Any time the user interface takes more than 50ms to respond to an action, it can appear sluggish to the user. To determine how often this happens, and what parts of our code are frequent offenders, we should add the ability to detect when the main-thread event loop is delayed by more than 50ms and log it as an ASSERT.
This feature falls primarily in the '''Experience''' category (from the "Discover, Experience, and Connect" vision statement.)
 
|Feature users and use cases=*provide insight to developers into what is causing the Firefox user interface to feel slow or unresponsive to users
== Release Requirements  ==
*identify high impact areas for UI responsiveness work
 
|Feature requirements=*Does not affect performance in production or beta builds  
*does not affect performance in production or beta builds  
*Can be logged to screen or file  
*can be logged to screen or file  
*Logging has been added to all primary user interface events
*logging has been added to all primary user interface events
|Feature non-goals=*provide information to end-users about what is causing Firefox to feel slow or unresponsive
 
*provide UI profiling
== Next Steps  ==
*integration of responsiveness testing into Talos
 
|Feature ux design=--[[User:Faaborg|Alex]] 20:16, 31 May 2011 (PDT): Here's a [http://people.mozilla.com/~faaborg/files/daf/eventVisualization.png possible UI for visualizing responsiveness].  Note that the 50ms ASSERT is for discrete actions, anything that is continuous would need to log when the responsiveness was higher than 16.6ms during the action.  In the visualization these appear as lines instead of dots (scrolling, moving the window, etc.)
*Complete project definition (ETA: 2011/04/01, Complete)  
|Feature security review=* No sec rev needed
*Work with UX to identify 15 primary UI events (ETA: 2011/04/01, [http://j.mp/ihM1wc google doc], Complete)
|Feature qa review=* No test plan needed
*Implement core instrumentation of event loop ({{bug|601268}}, Complete)  
|Feature implementation notes===== Next Steps ====
*Investigate options for correlation of event loop delays with high and low level code
*Identify top 10 code points causing event loop delays
 
== Related Bugs &amp; Dependencies ==
 
'''Tracking Bugs'''
 
*{{bug|651580}} - main project tracking bug
 
'''Related Bugs'''


*{{bug|601268}} - adds "canary in a coal mine" instrumentation to nsThread.cpp
* Analyze logs from JS function calls and event loop instrumentation to determine if the correlations are useful or not (see {{bug|653701}})
*{{bug|606574}} - adds ability to report information in Talos
* If useful, get {{bug|580055}} landed asap, so we don't have to keep unrotting it
*TBD - adds ability to dump JS function calls executed
* Correlate platform code unresponsiveness with event loop log (telemetry)
*TBD - adds ability to hook into a profiler (eg Shark)
* Hooks to trigger profiling tools on event loop unresponsiveness (eg: Shark, CHUD, Instrument, Systemtap, xperf)
* Instrument front-end UI actions (telemetry output?)
* Write HOWTO for easy correlation of code/actions to unresponsiveness
* Identify top 10 slowest-responding primary UI actions
* Identify top 10 platform code points causing event loop delays
* Fix the above


'''Related Documents'''  
''' Completed '''


*''no test plan needed''
* Complete project definition (ETA: 2011/04/01, Beltzner, Complete)
*''no product marketing plan needed''
* Work with UX to identify 15 primary UI events (ETA: 2011/04/01, [http://j.mp/ihM1wc google doc], Dietrich, Complete)
* Implement core instrumentation of event loop ({{bug|601268}}, Ted, Complete)


== Team ==
==== Related Bugs &amp; Dependencies ====


Anyone interested in this project is encouraged to jump in and get involved. The list here is to provide contact and ownership information:
* {{bug|651580}} - tracking bug
* [https://bugzilla.mozilla.org/showdependencygraph.cgi?id=651580 dependency graph]
* Related Bugs'''
** {{bug|601268}} - adds "canary in a coal mine" instrumentation to nsThread.cpp (MOZ_CANARY)
** {{bug|606574}} - add event loop responsiveness instrumentation (MOZ_INSTRUMENT_EVENT_LOOP_OUTPUT)
** {{bug|653701}} - Figure out a way to correlate JavaScript execution with event loop non-responsiveness
** {{bug|653703}} - Correlate C++ profiling with event loop non-responsiveness
** {{bug|580055}} - log all JS function entry/exits
** {{bug|667036}} - Add support for using DTPerformanceSession from javascript


*'''Development Lead:''' dietrich
'''Related Projects'''
*'''Infrastructure Lead:''' ted
* [https://github.com/autonome/about-response About:Response] - add-on that tracks response time of browser features
 
== Designs  ==
 
No designs required
 
== Goals/Use Cases  ==
 
*provide insight to developers into what is causing the Firefox user interface to feel slow or unresponsive to users
*identify high impact areas for UI responsiveness work
 
== Non-Goals  ==
 
*provide information to end-users about what is causing Firefox to feel slow or unresponsive
*provide UI profiling


'''Related Documents'''
* [https://wiki.mozilla.org/Fennec/Features/Gestures Fennec Gestures project] - lists a bunch of features identified
}}
{{FeatureInfo
|Feature priority=P1
|Feature rank=3
|Feature roadmap=User Experience
|Feature list=Desktop
|Feature engineering team=Desktop front-end
}}
{{FeatureTeamStatus
|Feature security status=pass
|Feature security notes=Determined no security review needed
|Feature qa status=OK with landing in Firefox 6
|Feature qa notes=Not a user facing feature. The dev team is taking the decision for the sign-off since it is a specific feature for product development
}}
== Other Documentation  ==
== Other Documentation  ==


*[http://www.useit.com/papers/responsetime.html Jakob Neilson's UseIt article on Response Time Limits for User Interfaces]
*[http://www.useit.com/papers/responsetime.html Jakob Neilson's UseIt article on Response Time Limits for User Interfaces]
== Security  ==
Security Contact: Curtis Koenig
*No security review necessarily for this feature
__NOTOC__
[[Category:Features]] [[Category:Firefox]] [[Category:Performance]] [[Category:P1]]
Confirmed users, Bureaucrats and Sysops emeriti
2,088

edits