MozillaWiki

Firefox/Features/50ms ASSERT: Difference between revisions

Page Discussion

Firefox/Features/50ms ASSERT (view source)

Revision as of 17:41, 10 July 2011

4,794 bytes removed ,  10 July 2011
m
clearing in prep for migration to new feature page format (will be done momentarily)
m (clearing in prep for migration to new feature page format (will be done momentarily))
Line 1: Line 1:
{| class="fullwidth-table"
|-
| 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
<section begin="status" />
|-
| [[Firefox/Features/50ms_ASSERT|Understand when user interface feels laggy]]
|{{StatusHealthy|status=Core instrumentation landed}}
SDR: N || SIR: N
| 2011-06-30
| [[User:Dietrich|dietrich]]
<section end="status" />
|}


== Summary  ==
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.
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.
There are generally two scenarios in which the browser UI is non-responsive.
# 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.
The goal of this project is to get developer visibility into both scenarios with easy-to-use tools.
== Release Requirements  ==
*Does not affect performance in production or beta builds
*Can be logged to screen or file
*Logging has been added to all primary user interface events
== Next Steps  ==
*Complete project definition (ETA: 2011/04/01, Beltzner, Complete)
*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)
*Investigate options for correlation of event loop delays with high and low level code (ETA: xxx, Ted, in progress)
*Investigate methods of identifying slow front-end UI (ETA: 2011/05/06, Dietrich, in progress)
*Identify and publish top 10 code points causing event loop delays (Ted)
*Identify and publish top 10 slowest-responding primary UI pieces (Dietrich)
*Publish the tools and methods developed in this project (Ted, Dietrich)
== 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 (MOZ_CANARY)
*{{bug|606574}} - add event loop responsiveness instrumentation (MOZ_INSTRUMENT_EVENT_LOOP_OUTPUT)
*{{bug|653701}} - adds ability to dump JS function calls executed when non-responsiveness is detected
*{{bug|653703}} - adds ability to hook into a profiler (eg Shark) when non-responsiveness is detected
*{{bug|580055}} - log all JS function entry/exits
'''Related Projects'''
* [https://github.com/autonome/about-response About:Response] - add-on that tracks response time of browser features
'''Related Documents'''
* [https://wiki.mozilla.org/Fennec/Features/Gestures Fennec Gestures project] - lists a bunch of features identified
*''no test plan needed''
*''no product marketing plan needed''
== Team  ==
Anyone interested in this project is encouraged to jump in and get involved. The list here is to provide contact and ownership information:
*'''Development Lead:''' dietrich
*'''Infrastructure Lead:''' ted
*'''QA contact''' Andrei (mirc: andreid)
== Designs  ==
No designs required
--[[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.)
== 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
*integration of responsiveness testing into Talos
== Other Documentation  ==
*[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]]
Dria
canmove, Confirmed users, Bureaucrats and Sysops emeriti
6,906

edits

Retrieved from "https://wiki.mozilla.org/Special:MobileDiff/327278"