Confirmed users
975
edits
Performance/Fenix/Performance reviews: Difference between revisions
Jump to navigation
Jump to search
Performance/Fenix/Performance reviews (view source)
Revision as of 00:25, 10 November 2021
, 10 November 2021→Example: time to display homescreen: Finish draft of example
(→Profile: Add more info to steps) |
(→Example: time to display homescreen: Finish draft of example) |
||
| Line 108: | Line 108: | ||
# 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, 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 '''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 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. | # 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. | |||
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. | |||