Firefox/Performance: Difference between revisions

← Older edit

Firefox/Performance (view source)

Revision as of 15:29, 27 February 2018

1,768 bytes added , 27 February 2018

→‎Submitting a Bug for Triage: Remove the priority flipping part

Mconley

Confirmed users, Bureaucrats and Sysops emeriti

1,004

edits

@@ Line 11: / Line 11: @@
 =Operating principals=
-Text goes here
+* 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=
@@ Line 53: / Line 79: @@
 ==Submitting a Bug for Triage==
-# Mark the bug as blocking the [https://bugzilla.mozilla.org/show_bug.cgi?id=photon-performance-triage photon-performance-triage] meta bug '''''or''''' add the [fxperf] tag to the whiteboard.
+# Mark the bug by adding the [fxperf] tag to the whiteboard.
-# Leave the priority field empty (--).
 <p> </p>