Firefox/Features/50ms ASSERT

From MozillaWiki
< Firefox‎ | Features
Revision as of 17:47, 10 July 2011 by Dria (talk | contribs) (migrated - hopefully i didn't miss anything.)
Jump to navigation Jump to search
Please use "Edit with form" above to edit this page.

Status

Understand when user interface feels laggy
Stage Landed
Status `
Release target Firefox 6
Health OK
Status note Core instrumentation landed. SDR: N SIR: N

{{#set:Feature name=Understand when user interface feels laggy

|Feature stage=Landed |Feature status=` |Feature version=Firefox 6 |Feature health=OK |Feature status note=Core instrumentation landed. SDR: N SIR: N }}

Team

Product manager `
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)

{{#set:Feature product manager=`

|Feature feature manager=Dietrich Ayala |Feature lead engineer=` |Feature security lead=Curtis Koenig |Feature privacy lead=` |Feature localization lead=` |Feature accessibility lead=` |Feature qa lead=AndreiD |Feature ux lead=` |Feature product marketing lead=` |Feature operations lead=` |Feature 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.

  1. 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.
  2. 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.

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

  • 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

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

Related Documents

Stage 5: Release

10. Landing criteria

` {{#set:Feature open issues and risks=` |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.

  1. 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.
  2. 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. |Feature users and 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

|Feature dependencies=` |Feature 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

|Feature 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

|Feature functional spec=` |Feature ux 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.) |Feature implementation plan=` |Feature security review=* No sec rev needed |Feature privacy review=` |Feature localization review=` |Feature accessibility review=` |Feature qa review=* No test plan needed |Feature operations review=` |Feature implementation notes===== 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

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

Related Documents

|Feature landing criteria=` }}

Feature details

Priority P1
Rank 999
Theme / Goal `
Roadmap User Experience
Secondary roadmap `
Feature list Desktop
Project `
Engineering team Desktop front-end

{{#set:Feature priority=P1

|Feature rank=999 |Feature theme=` |Feature roadmap=User Experience |Feature secondary roadmap=` |Feature list=Desktop |Feature project=` |Feature engineering team=Desktop front-end }}

Team status notes

  status notes
Products tbd `
Engineering tbd `
Security tbd `
Privacy tbd `
Localization tbd `
Accessibility tbd `
Quality assurance tbd `
User experience tbd `
Product marketing ` `
Operations ` `

{{#set:Feature products status=tbd

|Feature products notes=` |Feature engineering status=tbd |Feature engineering notes=` |Feature security status=tbd |Feature security health=` |Feature security notes=` |Feature privacy status=tbd |Feature privacy notes=` |Feature localization status=tbd |Feature localization notes=` |Feature accessibility status=tbd |Feature accessibility notes=` |Feature qa status=tbd |Feature qa notes=` |Feature ux status=tbd |Feature ux notes=` |Feature product marketing status=` |Feature product marketing notes=` |Feature operations status=` |Feature operations notes=` }}


Other Documentation

Retrieved from "https://wiki.mozilla.org/index.php?title=Firefox/Features/50ms_ASSERT&oldid=327279"