Firefox/Features/50ms ASSERT: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
No edit summary
No edit summary
Line 1: Line 1:
<section begin="status" />
{| class="fullwidth-table"
{| class="fullwidth-table"
|-
|-
| style="font-weight: bold; background: #DDD;" | Feature
| style="font-weight: bold; background: #DDD;" | Feature  
| style="font-weight: bold; background: #DDD;" | Status
| style="font-weight: bold; background: #DDD;" | Status  
| style="font-weight: bold; background: #DDD;" | ETA
| style="font-weight: bold; background: #DDD;" | ETA  
| style="font-weight: bold; background: #DDD;" | Owner
| style="font-weight: bold; background: #DDD;" | Owner
|-
|-
<section begin="status" />
| [[Firefox/Features/50ms_ASSERT|ASSERT when UI is delayed by more than 50ms]]  
| [[Firefox/Features/50ms_ASSERT|ASSERT when UI is delayed by more than 50ms]]
|  
| {{StatusHealthy|status=Core instrumentation landed}}
{{StatusHealthy|status=Core instrumentation landed}}
| 2011-04-29
 
| [[User:Dietrich|dietrich]]
SDR: N &#124;&#124; SIR: N <br>
<section end="status" />
 
|-
| 2011-04-29  
| [[User:Dietrich|dietrich]]  
<section end="status" />  
 
|}
|}


== Summary ==
== 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.
 
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.  
 
== 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, Complete)
*Work with UX to identify 15 primary UI events (ETA: 2011/04/01, [http://j.mp/ihM1wc google doc], Complete)
*Implement core instrumentation of event loop ({{bug|601268}}, Complete)
*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
*{{bug|606574}} - adds ability to report information in Talos
*TBD - adds ability to dump JS function calls executed
*TBD - adds ability to hook into a profiler (eg Shark)
 
'''Related Documents'''
 
*''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


== Release Requirements ==
== Designs  ==
* 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 ==
No designs required
* Complete project definition (ETA: 2011/04/01, Complete)
* Work with UX to identify 15 primary UI events (ETA: 2011/04/01, [http://j.mp/ihM1wc google doc], Complete)
* Implement core instrumentation of event loop ({{bug|601268}}, Complete)
* 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 & Dependencies ==
== Goals/Use Cases  ==
'''Tracking Bugs'''
* {{bug|651580}} - main project tracking bug


'''Related Bugs'''
*provide insight to developers into what is causing the Firefox user interface to feel slow or unresponsive to users
* {{bug|601268}} - adds "canary in a coal mine" instrumentation to nsThread.cpp
*identify high impact areas for UI responsiveness work
* {{bug|606574}} - adds ability to report information in Talos
* TBD - adds ability to dump JS function calls executed
* TBD - adds ability to hook into a profiler (eg Shark)


'''Related Documents'''
== Non-Goals  ==
* ''no test plan needed''
* ''no product marketing plan needed''


== Team ==
*provide information to end-users about what is causing Firefox to feel slow or unresponsive
Anyone interested in this project is encouraged to jump in and get involved. The list here is to provide contact and ownership information:
*provide UI profiling


* '''Development Lead:''' dietrich
== Other Documentation  ==
* '''Infrastructure Lead:''' ted


== Designs ==
*[http://www.useit.com/papers/responsetime.html Jakob Neilson's UseIt article on Response Time Limits for User Interfaces]
No designs required


== Goals/Use Cases ==
== Security  ==
* 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 ==
Security Contact: Curtis Koenig
* provide information to end-users about what is causing Firefox to feel slow or unresponsive
* provide UI profiling


== Other Documentation ==
*No security review necessarily for this feature
* [http://www.useit.com/papers/responsetime.html Jakob Neilson's UseIt article on Response Time Limits for User Interfaces]


== Security ==
__NOTOC__  
Security Contact: Curtis Koenig
* No security review necessarily for this feature
__NOTOC__


[[Category:Features]] [[Category:Firefox]] [[Category:Performance]] [[Category:P1]]
[[Category:Features]] [[Category:Firefox]] [[Category:Performance]] [[Category:P1]]

Revision as of 21:33, 26 April 2011

Feature Status ETA Owner
ASSERT when UI is delayed by more than 50ms

style="background:#9D9;" | 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.

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, Complete)
  • Work with UX to identify 15 primary UI events (ETA: 2011/04/01, google doc, Complete)
  • Implement core instrumentation of event loop (bug 601268, Complete)
  • 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 & Dependencies

Tracking Bugs

Related Bugs

  • bug 601268 - adds "canary in a coal mine" instrumentation to nsThread.cpp
  • bug 606574 - adds ability to report information in Talos
  • TBD - adds ability to dump JS function calls executed
  • TBD - adds ability to hook into a profiler (eg Shark)

Related Documents

  • 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

Other Documentation

Security

Security Contact: Curtis Koenig

  • No security review necessarily for this feature
Retrieved from "https://wiki.mozilla.org/index.php?title=Firefox/Features/50ms_ASSERT&oldid=302979"