Firefox/Features/50ms ASSERT
| Feature | Status | ETA | Owner |
| ASSERT when UI is delayed by more than 50ms | Core instrumentation landed
SDR: N || SIR: N |
2011-04-29 | dietrich |
Summary
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.
Update: There are two general scenarios in which UI is non-responsive. The first scenario is when a direct action by the user causes the app to be non-responsive. For example, a menu option with executes an action synchronously, and which takes >50ms to return. The second scenario is that some background action blocks the event loop for >50ms, causing the app to be generally non-responsive. We're working to get visibility into both scenarios.
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, 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 & Dependencies
Tracking Bugs
- bug 651580 - main project tracking bug
Related Bugs
- bug 601268 - adds "canary in a coal mine" instrumentation to nsThread.cpp
- bug 606574 - adds ability to report information in Talos
- 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
Related Projects
- About:Response - add-on that tracks response time of browser features
Related Documents
- 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
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
- integration of responsiveness testing into Talos
Other Documentation
Security
Security Contact: Curtis Koenig
- No security review necessarily for this feature