Confirmed users, Bureaucrats and Sysops emeriti
1,004
edits
Firefox/Performance: Difference between revisions
→Submitting a Bug for Triage: Remove the priority flipping part
m (Tweak the triage instructions.) |
(→Submitting a Bug for Triage: Remove the priority flipping part) |
||
| (5 intermediate revisions by the same user 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> | ||