Firefox OS/Performance/Datazilla

From MozillaWiki
Jump to: navigation, search


This page details Datazilla and how we use it to triage performance problems in Firefox OS.


Data in Datazilla is currently always submitted by the Python based b2gperf tool, however the data can be collected either using b2gperf itself or Gaia's performance tests. The b2gperf tests use b2gpopulate to push reference workloads to the device, however the reference-workload targets are used ahead of the Gaia performance tests. The long term plan is to retire b2gperf once the Gaia performance tests provide equal or better coverage and are capable of uploading directly to Datazilla. There is a Jenkins instance in Mountain View which runs the automated tests against physical devices.

Current Tests

Cold Load Time

The b2gperf tool measures time taken from launching an app to the apploadtime event firing. This generates app startup times which are useful for identifying some kinds of performance regressions, but which are much shorter than camera-based startup times measured by Eideticker.

Any app should work with b2gperf for gathering cold load times, however the following will also populate reference workloads:

Application Workload
Contacts 200 contacts
Gallery 700 pictures
Messages 200 messages
Music 500 tracks
Video 100 videos

The full list of applications currently tested is below, however this may become out of date and the best place to check the latest list is in Jenkins or Datazilla:

  • Phone
  • Contacts
  • Messages
  • Settings
  • Gallery
  • Video
  • Music
  • Camera
  • Email
  • Calendar
  • Clock
  • FM Radio
  • Usage
  • Template
  • Browser


  • Endurance: Gaia UI tests that perform the same few interactions repeatedly in order to identify memory leaks or performance issues. These are run infrequently due to the amount of time they take to run.

Gaia Tests

See Gaia Performance test.

  • Startup Time: This is gathered using the 'test-perf' make target with Gaia, and the data is submitted to Datazilla using b2gperf. The test-perf jobs can measure other arbitrary performance metrics that are designed by the test authors (like "rendering_WiFi_list_>_settings-panel-wifi-ready"); the job that submits data to datazilla can operate on arbitrary metric names without any changes to the datazilla infrastructure. All the logic which runs these tests is part of Gaia; the output of 'make test-perf' includes a JSON structure which b2gperf submits to datazilla.

Here is an example flow of an app using the startup time test today: Process Startup -> Start Timer -> Make API calls -> Onload Event (Fire startup time event) -> API calls return, app useable.

There are a few problems with this test:

    • The time between Process Startup and starting the timer is not constant. Ideally we would start the timer before we run startup. I was informed that this was difficult. TODO: File a bug if this does not exist.
    • The startup time can be taken before the app is really ready. There are bugs open to add "startup path done" tests for the various apps.

apploadtime: The event which we listen on for Startup Time and Cold Load Time tests. Gaia fires the apploadtime event, after listening to the gecko mozbrowserloadend event. Happens after all deferred scripts are loaded. This is the same as the load event. (There is no load event on a moz browser). We have to look at the code for each app to see exactly when this happens.

Triaging Regressions

Each point in datazilla has a gaia, gecko, and platform build revision id. You can use this information to triage and locate where the regression occurred.

Git Bisect

You can use git bisect to narrow down the range between two datapoints. This is useful for finding offending gaia commits. You can select two adjacent ranges and git bisect from one to another. Git bisect tutorial:


One way of doing this is to use the B2G profiler: More information on profiling: