Performance/Fenix/Performance reviews

Whenever submitting a PR for Fenix or Focus and you believe that the changed code could have a positive (or negative) impact on performance, there are a few things you can do to test the impact of the modified code.

Testing Start Up code

To test start up code, the approach is usually simple:

1. From the mozilla-mobile/perf-tools repository, use measure_start_up.py.
   The arguments for start-up should include your target (Fenix or Focus).
2. Determine the start-up path that your code affects this could be:
   1. Cold main first frame (cold_main_first_frame in the script) . This is the first frame drawn by the application. This path is taken by all "type" of start-ups
   2. Cold view nav start (cold_view_nav_start in the script) . This path is taken when the browser is opened through an outside link (i.e: a link opened through Ggmail)
   3. Cold main session restore (cold_main_session_restore in the script) . This path is taken when the browser was closed with an opened tab. When reopening, the application will automatically restore that session.
3. After determining the path your changes affect, these are the steps that you should follow:

Example:

• Run measure_start_up.py located in perf-tools. Note:
  • The usual iteration coumbered list itemnts used is 25. Running less iterations might affect the results due to noise
  • Make sure the application you're testing is a fresh install. If testing the Main intent (which is where the browser ends up on its homepage), make sure to clear the onboarding process before testing

 python3 measure_start_up.py cold_view_nav_start /Users/computername/repositories/fenix/ nightly -p fenix -c 50 --no_start_up_cache

where p is the product, c is the iteration count

• Once you have gathered your results, you can analyze them using analyze_durations.py in perf-tools.

  python3 analyze_durations.py /Users/computername/output/measure_start_up_results.txt

NOTE:For testing before and after to compare changes made to Fenix: repeat these steps, but this time for the code before the changes. Therefore, you could checkout the parent comment (I.e: using git rev-parse ${SHA}^ where ${SHA} is the first commit on the branch where the changes are)

An example of using these steps to review a PR can be found (here).

Testing non start-up changes

Testing for non start-up changes is a bit different than the steps above since the performance team doesn't have tools as of now to test different part of the browser.

1. The first step here would be to instrument the code to take (manual timings). By getting timings before and after the changes, it could potentially indicate any changes in performance.
2. Using profiles and markers.
   1. (Profiles) can be a good visual representative for performance changes. A simple way to find your code and its changes could be either through the call tree, the flame graph or stack graph. NOTE: some code may be missing from the stack since pro-guard may inline it, or the sampling rate of the profiler is more than the time taken by the code.
   2. Another useful tool to find changes in performance is markers. Markers can be good to show the time elapsed between point A and point B or to pin point when a certain action happens.