Firefox/Features/50ms ASSERT
Status
| Primary UI Responsiveness - 50ms goal | |
| Stage | Complete |
| Status | ` |
| Release target | ` |
| Health | OK |
| Status note | Core instrumentation landed, resulting in various tools built on top of it. Current work utilizing these tools is the Snappy project. SDR: N SIR: N |
Team
| Product manager | Asa Dotzler |
| Directly Responsible Individual | Dietrich Ayala |
| Lead engineer | ` |
| Security lead | Curtis Koenig |
| Privacy lead | ` |
| Localization lead | ` |
| Accessibility lead | ` |
| QA lead | AndreiD |
| UX lead | ` |
| Product marketing lead | ` |
| Operations lead | ` |
| Additional members | ted (infrastructure lead) |
Open issues/risks
`
Stage 1: Definition
1. 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.
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.
This feature falls primarily in the Experience category (from the "Discover, Experience, and Connect" vision statement.)
2. Users & 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
3. Dependencies
`
4. 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
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
Stage 2: Design
5. Functional specification
`
6. User experience design
--Alex 20:16, 31 May 2011 (PDT): Here's a 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.)
Stage 3: Planning
7. Implementation plan
`
8. Reviews
Security review
- No sec rev needed
Privacy review
`
Localization review
`
Accessibility
`
Quality Assurance review
- No test plan needed
Operations review
`
Stage 4: Development
9. Implementation
Next Steps
- Analyze logs from JS function calls and event loop instrumentation to determine if the correlations are useful or not (see bug 653701)
- If useful, get bug 580055 landed asap, so we don't have to keep unrotting it
- Correlate platform code unresponsiveness with event loop log (telemetry)
- 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
Completed
- 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)
Related Bugs & Dependencies
- bug 651580 - tracking bug
- 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
Related Projects
- About:Response - add-on that tracks response time of browser features
Related Documents
- Fennec Gestures project - lists a bunch of features identified
Stage 5: Release
10. Landing criteria
`
Feature details
| Priority | P1 |
| Rank | 3 |
| Theme / Goal | ` |
| Roadmap | User Experience |
| Secondary roadmap | ` |
| Feature list | Desktop |
| Project | ` |
| Engineering team | Desktop front-end |
Team status notes
| status | notes | |
| Products | ` | ` |
| Engineering | ` | ` |
| Security | pass | Determined no security review needed |
| Privacy | ` | ` |
| Localization | ` | ` |
| Accessibility | ` | ` |
| Quality assurance | OK with landing in Firefox 6 | 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 |
| User experience | ` | ` |
| Product marketing | ` | ` |
| Operations | ` | ` |
