Performance/Fenix/Profilers and Tools

From MozillaWiki
Jump to: navigation, search

Measuring performance has a few major approaches:

If you need more assistance with android performance testing, please reach out to us on the #perf-android-frontend channel on Matrix.

Profilers and performance tooling

Important note: this approach will create overhead and give less accurate time values. This method is useful when you are looking for red flags in your code and trying to diagnose performance issues. If you want accurate measurements, see timestamp measurement or performance tests.

There are different tools at your disposal. Each of them has a specific use case and the details are below.

  1. The Firefox Profiler / Gecko Profiler (documentation) is the preferred profiler. This profiler allows us to profile the code with lower overhead and non-debuggable builds including APKs from the Play Store, capture native code, and share profiles right in the browser. The UX is just so much better. :) You should try another profiler if you:
    1. Need access to Java threads other than the main thread (issue )
    2. Are profiling application start up and some information is missing (bug 1659103)
  2. The Debug API (documentation) is most useful when you:
    1. Need access to Java threads other than the main thread
    2. Are profiling application start up and want to capture it early (when the application can start executing code)
    The profiles have non-trivial overhead (a few hundred ms in a 1.5-2.5s start up) and seem to be more representative than the Android Profiler. See Performance/Fenix/Debug API for a how-to guide on usage in Firefox.
  3. The Android Profiler (documentation) is most useful when you want the benefits of the `Debug` API but cannot instrument the code. The results in the Android Profiler are very misleading: what you see in profiles may not accurately represent what users’ experience in release builds. This is due to the debuggable=true requirement which causes different methods to increase in runtime inconsistently (further explanation). For example, in the AS Profiler, we’ve seen that UI layout is proportionally longer than business logic than in production builds.

Advanced tools:

  1. Perfetto (official documentation) is a comprehensive tracing profiler developed by Google for Android, Chrome, and other applications. It uses many Linux profiling facilities to get information about the application as well as OS-level information (e.g. which CPU is scheduled, what's the frequency, how does disk IO look, etc.). We haven't explored this thoroughly but it seems useful and is easy to run on modern Android devices
  2. Simpleperf (official documentation; follow the Fenix-specific steps found in this README) is most useful when you want:
    1. The benefits of the Debug API
    2. To capture the start up trace even earlier (at process start)
    3. To capture native traces

    It appears to have low overhead. However, it’s difficult to set up and will only be able to profile start up with rooted phones.

  3. Nanoscope is another tool that can be useful to profile non-debuggable applications. (documentation). We would only suggest to use this tool whenever profiling start up has failed with the previous options.

Timestamp measurement

In order to have a precise understanding of the impact of your changes on performance, you need to measure what the user experiences with little overhead. In practice, this is done by instrumenting your code with timestamps and outputting to Logcat. Measuring your changes can go wrong in many ways, so please reach out to us at #perf-android-frontend on Matrix so that we can explain what to look out for.

If you decide to jump in anyway, you’ll need to:

Performance tests

These aren't ready for broader use yet – please contact us for questions!