Firefox/Performance: Difference between revisions
(Add meeting notes link) |
(→Submitting a Bug for Triage: Remove the priority flipping part) |
||
(8 intermediate revisions by 2 users not shown) | |||
Line 1: | Line 1: | ||
=Firefox Desktop Perceived Performance Team= | =Firefox Desktop Perceived Performance Team= | ||
The purpose of this team is to improve the perceived performance of Firefox. Our focus is mostly on front-end code that impacts the perceived performance of the browser itself, not the performance of rendering web pages. There are other teams focused on the latter. | |||
=Members= | =Members= | ||
Line 9: | Line 9: | ||
* Philipp Sackl (:phlsa) | * Philipp Sackl (:phlsa) | ||
* Panos Astithas (:past) | * Panos Astithas (:past) | ||
=Operating principals= | |||
* Our work should impact key user interactions of the browser front-end. From a high-level, these are: | |||
** Browser startup | |||
** Tab operations | |||
*** Opening | |||
*** Closing | |||
*** Switching | |||
*** Drag and drop | |||
*** Scrolling | |||
** Window operations | |||
*** Opening | |||
*** Closing | |||
*** Focusing | |||
** Menu operations | |||
*** Opening | |||
*** Closing | |||
*** Navigating submenus / subviews | |||
** URL bar operations | |||
*** Showing the URL bar panel | |||
*** Showing results in the URL bar panel | |||
** Jank, real or perceived slowness that can occur at seemingly random times in the parent process | |||
** Browser shutdown | |||
* If you notice a pattern of performance issues, it is better to try to address the pattern in general than to spot fix individual instances. | |||
** The playbook is usually: create a whitelist of pre-existing cases of the bad behaviour to make adding new cases impossible, then whittle down the whitelist. Once the whitelist is empty, remove the whitelist. | |||
** '''Example''': Making main-thread IO impossible is better than fixing a single instance of main-thread IO. We should aim to have a whitelist of places where main-thread IO is currently used, and crash if new main-thread IO is added. We should then file bugs to whittle down the whitelist. | |||
* If you improve something, try to write regression tests to ensure it doesn't get worse. Mochitests are preferred, as Talos tests can be too noisy to be truly useful. | |||
** '''Example:''' We moved a lot of scripts so that they don't run until after first paint. There are still some scripts remaining, and we've added a whitelist for those scripts. This ensures that the problem we identified cannot get worse, and only better. | |||
** '''Example:''' We've eliminated some synchronous layout flushes caused by our JavaScript code, and have written tests to exercise the user interactions that caused them. Those tests ensure that a whitelist of synchronous layout flushes are possible, which makes it much harder to accidentally add new ones in the future. | |||
=Contact= | =Contact= | ||
Line 50: | Line 79: | ||
==Submitting a Bug for Triage== | ==Submitting a Bug for Triage== | ||
# Mark the bug | # Mark the bug by adding the [fxperf] tag to the whiteboard. | ||
<p> </p> | <p> </p> | ||
Line 58: | Line 86: | ||
|- | |- | ||
| | | | ||
Collection of work waiting for the team to review and determine if it should be included in the Product Backlog - [https://bugzilla.mozilla.org/showdependencytree.cgi?id=1348289&hide_resolved=1 View in Bugzilla] | Collection of work waiting for the team to review and determine if it should be included in the Product Backlog | ||
<p> </p> | |||
Bugs blocking photon-performance-triage - [https://bugzilla.mozilla.org/showdependencytree.cgi?id=1348289&hide_resolved=1 View in Bugzilla] | |||
<p> </p> | <p> </p> | ||
<bugzilla> | <bugzilla> | ||
Line 64: | Line 94: | ||
"include_fields": ["id", "summary", "status", "whiteboard", "keywords", "assigned_to"], | "include_fields": ["id", "summary", "status", "whiteboard", "keywords", "assigned_to"], | ||
"blocks": ["1348289"], | "blocks": ["1348289"], | ||
"resolution": "---" | |||
} | |||
</bugzilla> | |||
|- | |||
| | |||
Tracked bugs without a priority set - [https://mzl.la/2l7ROND View in Bugzilla] | |||
<p> </p> | |||
<bugzilla> | |||
{ | |||
"whiteboard": "[fxperf]", | |||
"include_fields": ["id", "summary", "status", "whiteboard", "keywords", "assigned_to"], | |||
"priority": "--", | |||
"resolution": "---" | "resolution": "---" | ||
} | } |
Latest revision as of 15:29, 27 February 2018
Firefox Desktop Perceived Performance Team
The purpose of this team is to improve the perceived performance of Firefox. Our focus is mostly on front-end code that impacts the perceived performance of the browser itself, not the performance of rendering web pages. There are other teams focused on the latter.
Members
- Mike Conley (:mconley)
- Florian Queze (:florian)
- Paolo Amadini (:paolo)
- Gijs Kruitbosch (:Gijs)
- Philipp Sackl (:phlsa)
- Panos Astithas (:past)
Operating principals
- Our work should impact key user interactions of the browser front-end. From a high-level, these are:
- Browser startup
- Tab operations
- Opening
- Closing
- Switching
- Drag and drop
- Scrolling
- Window operations
- Opening
- Closing
- Focusing
- Menu operations
- Opening
- Closing
- Navigating submenus / subviews
- URL bar operations
- Showing the URL bar panel
- Showing results in the URL bar panel
- Jank, real or perceived slowness that can occur at seemingly random times in the parent process
- Browser shutdown
- If you notice a pattern of performance issues, it is better to try to address the pattern in general than to spot fix individual instances.
- The playbook is usually: create a whitelist of pre-existing cases of the bad behaviour to make adding new cases impossible, then whittle down the whitelist. Once the whitelist is empty, remove the whitelist.
- Example: Making main-thread IO impossible is better than fixing a single instance of main-thread IO. We should aim to have a whitelist of places where main-thread IO is currently used, and crash if new main-thread IO is added. We should then file bugs to whittle down the whitelist.
- If you improve something, try to write regression tests to ensure it doesn't get worse. Mochitests are preferred, as Talos tests can be too noisy to be truly useful.
- Example: We moved a lot of scripts so that they don't run until after first paint. There are still some scripts remaining, and we've added a whitelist for those scripts. This ensures that the problem we identified cannot get worse, and only better.
- Example: We've eliminated some synchronous layout flushes caused by our JavaScript code, and have written tests to exercise the user interactions that caused them. Those tests ensure that a whitelist of synchronous layout flushes are possible, which makes it much harder to accidentally add new ones in the future.
Contact
Team Meeting
Day of week | Pacific Time | Eastern Time | UTC | Central European Time |
---|---|---|---|---|
Fridays | 8:30AM - 9:00AM | 11:30AM - 12:00PM | 4:30PM - 5:00PM | 5:30PM - 6:00PM |
- Frequency: One meeting per week on Friday.
- Duration: 30 min
- Vidyo Room: Firefox
- Meeting notes: Google Doc
- IRC: #fx-team
- Mailing list: firefox-dev
Bugzilla
Bugzilla components don't tend to align properly with this project's boundaries, so this team is monitoring bugs across a number of components that block the photon-performance meta bug. Here is the dependency tree. Common components of interest are Firefox:General, Firefox:Tabbed Browser, Toolkit:General and more.
Selecting a New Bug for the Current Release
- Select any 'P1' bug which is currently unassigned and not blocked on a dependency. If no 'P1' bugs are available then select from the available 'P2' bugs, and so on.
- Add the following if not already present:
- [fxperf] whiteboard tag.
- perf keyword.
- qe-verify-, unless it is a bug that QA can reasonably verify.
Adding a New Bug to the Backlog
- Add the [fxperf] tag to the whiteboard.
- Add the perf keyword.
- Set the bug as a dependency of a user story bug or a meta bug if applicable.
- Set the bug priority per the following guidelines or call it out for a priority decision in the Weekly Meeting:
- 'P1': Must Have - development occurring in the current release.
- 'P2': Should Have - targeted for next release.
- 'P3': Could Have - planned for development in an upcoming release.
- 'P5': Will Have - not scheduled for any particular release, patches accepted.
Submitting a Bug for Triage
- Mark the bug by adding the [fxperf] tag to the whiteboard.
Releases
Current Release |
---|
P1: Must Have - development occurring in the current release - View in Bugzilla Duration: Tuesday January 23 - Monday March 12
No results. 0 Total; 0 Open (0%); 0 Resolved (0%); 0 Verified (0%); |
Current Release: Completed | |||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
6 Total; 0 Open (0%); 6 Resolved (100%); 0 Verified (0%); |
Next Release |
---|
P2: Should Have - targeted for the current release if production capacity exists - View in Bugzilla No results. 0 Total; 0 Open (0%); 0 Resolved (0%); 0 Verified (0%); |
Backlog | ||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
P3: Could Have - planned for development in an upcoming release - View in Bugzilla
5 Total; 5 Open (100%); 0 Resolved (0%); 0 Verified (0%); |
Patches Accepted | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
P5: Will Have - not scheduled for any particular release, patches accepted - View in Bugzilla
1 Total; 1 Open (100%); 0 Resolved (0%); 0 Verified (0%); |
¯\_(ツ)_/¯ | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
P4: (should be reprioritized to P3 or P5) - View in Bugzilla
1 Total; 1 Open (100%); 0 Resolved (0%); 0 Verified (0%); |