Performance/Fenix/Performance reviews: Difference between revisions

Performance/Fenix/Performance reviews (view source)

Revision as of 18:31, 10 November 2021

108 bytes added , 10 November 2021

→‎Profile: Clean up results

Mcomella

Confirmed users

975

edits

@@ Line 98: / Line 98: @@
 == Profile ==
-You can [https://profiler.firefox.com/docs/#/./guide-remote-profiling take profiles with the Firefox Profiler], identify the start and end points for the duration you're measuring in your profile, and use the difference between them to measure the duration. It's quick to take these profiles but there are big downsides: profilers add overhead so the duration will not be precise, it's difficult to avoid noise in the results because devs will only take a few profiles, and it may be non-trivial to correctly identify the start and end points of the duration especially when the implementations you compare have big differences.
+You can [https://profiler.firefox.com/docs/#/./guide-remote-profiling take profiles with the Firefox Profiler], identify the start and end points for the duration you're measuring in your profile, and use the difference between them to measure the duration. It's quick to take these profiles but there are big downsides: profilers add overhead so the duration will not be precise, it's difficult to avoid noise in the results because devs can only take so many profiles, and it may be non-trivial to correctly identify the start and end points of the duration especially when the implementations you compare have big differences.
 Follow the example below to see how to measure the change in duration for a change with profiles.
@@ Line 106: / Line 106: @@
 # We pick the specific duration we want to measure: the time from hitting the home button when a tab is open until the homescreen is visually complete.
 # We build & install a '''release build''' (e.g. Nightly, Beta; debug builds have unrepresentative perf). You can also use a recent Nightly, like this example does.
-# We '''do a "warm up" run''' to populate the JIT's cache (the first run has unrepresentative perf). We start the app, open a tab, do our use case (click the home button and wait for the UI to fully load). Then we force-stop the app.
+# We '''do a "warm up" run''' to populate the JIT's cache (the first run has unrepresentative perf). We start the app, set up the start state (open a tab), do our use case (click the home button and wait for the UI to fully load). Then we force-stop the app.
-# We '''measure:''' start the app (which should launch to the most recent tab), start the profiler (see [https://profiler.firefox.com/docs/#/./guide-remote-profiling here for instructions]), perform the use case (click the home button in the toolbar and wait for the homescreen to finish loading), and stop the profiler. If necessary, we enable the profiler (3-dot menu -> Settings -> Remote debugging via USB).
+# We '''profile:''' start the app (which should launch to the most recent tab), start the profiler (see [https://profiler.firefox.com/docs/#/./guide-remote-profiling here for instructions]), perform the use case (click the home button in the toolbar and wait for the homescreen to finish loading), and stop the profiler. Don't forget to enable the profiler permissions (3-dot menu -> Settings -> Remote debugging via USB).
 # We identify the duration of the change [https://share.firefox.dev/3odXiYR in the raw profile]. The most accurate and reproducible way to do this is using the Marker Chart.
 ## In this case, we can identify '''the start point''' through the <code>dispatchTouchEvent ACTION_UP</code> marker, right-click it, and choose "Start selection here" to narrow the profile's timeline range. We can then click the magnifying glass with the + in the timeline to clamp the range.
-## '''The end point''' is more tricky: we don't have a marker to identify that the UI is visually complete. As such, we can use the information in the Marker Chart and Stack Chart to make a best guess as to when the UI is visually complete (notice that this creates a point of inaccuracy). If we temporarily clamp our range to after the last marker (<code>onGlobalLayout</code>) is run, [https://share.firefox.dev/3ccSWfb we see that there is a measure/layout pass for Compose]. We'll assume this measure/layout is not redundant so that the content isn't visually complete until this last measure/layout pass, and the draw that follows it, completes. To clamp the range to this, we can double-click on the <code>draw</code> method above <code>measureAndLayout</code> to shrink our range to that method – this lets us accurately capture the end point. Then we can expand the range all the way to the left, back to our selected start point. Then we can clamp the range. The final profile – https://share.firefox.dev/3o7EvOI – gives us our final duration, which we can see in the value at the very top of the profiler: 1.4s in this case.
+## '''The end point''' is more tricky: we don't have a marker to identify that the UI is visually complete. As such, we can use the information in the Marker Chart and Stack Chart to make a best guess as to when the UI is visually complete (notice that this creates a point of inaccuracy). If we temporarily clamp our range to after the last marker (<code>onGlobalLayout</code>) is run, [https://share.firefox.dev/3ccSWfb we see that there is a measure/layout pass for Compose after it]. We make a best guess that the content isn't visually complete until this last measure/layout/draw pass completes. To clamp the range to this, we can double-click on the <code>draw</code> method above <code>measureAndLayout</code> to shrink our range to that method – this lets us accurately capture the end point. Then we can drag the selection handle to re-expand the range all the way to the left, back to our start point. Then we can clamp the range given that the start and end points we want to measure are the start and end points of the range. The final profile – https://share.firefox.dev/3o7EvOI – gives us our final duration, which we can see in the value at the top left of the profiler: 1.4s in this case.
-With the measurement in hand, repeat these steps for your changed and compare the resulting times. Note: it's possible the device was under load when you took the profile so you may wish to take more than one profile if you suspect that is the case.
+With the measurement in hand, repeat these steps for your changes and compare the resulting times. Note: it's possible the device was under load when you took the profile so you may wish to take more than one profile if you suspect that is the case.