Hello, As of today, Datazilla is now updated to use the new launch events and low-memory configuration as its default view for B2G performance. Visiting https://datazilla.mozilla.org/b2g/ will display visualizations for all apps supporting the new launch event of "moz-app-visually-complete", using the 319MB Flame as the reference.
*What does this mean?* As discussed during last week's Gaia weekly meeting, the use of the "apploadtime" and consequently the `window load` event was a poor indicator for an app to determine its launch time. By deferring the loading of assets, an app could change the cold load measurement without any perceivable user impact, in essence shifting things around without actually improving the launch time. In bug 996038 <https://bugzilla.mozilla.org/show_bug.cgi?id=996038> [1] we sought to solve this by using app-implied events throughout the launch lifecycle of each application. *What is being displayed?* When Datazilla loads this default view, the first thing to note is the test that is being run: "startup > moz-app-visually-complete". According to MDN [2]: *Emit this event when your application designates that it is visually loaded, e.g. the "above-the-fold" content exists in the DOM and you have marked it as ready to be display, not display: none; or other hiding functionality.* In other words, this test measures how long it took for the app to get to a state where the user perceives the app as ready to use. (As an aside, the other events discussed on MDN are also available for viewing within the Datazilla UI.) The next two important parts are the branch and the device. The device selected is a Flame configured to 319MB of memory. This is the default low-memory configuration. The Flame-512MB is also available. The default branch is master, and these events were uplifted to v2.0 so you may view and compare with that branch as well. *How do I use this?* Looking at this view, make sure your target application is selected on the left-hand side. You may choose to unselect all apps you aren't interested in to reduce visual clutter. Viewing the timeline shown, the goal is for the launch time of an application to remain steady or undergo a reduction as patches are landed which improve its launch time. If the values increase and remain that way, it's a good sign of a regression in the launch time. You will want to identify the patch that caused the regression, be it either Gaia or Gecko, and determine if a back-out is necessary, or other follow-ups. Selecting any data point will display a secondary chart with the launch time of each individual run; each test runs 30 times against every app. Also displayed with each data point is the Gaia git revision and Gecko hg revision for assistance with regression determination and bisecting. By following instructions for the Gaia performance tests [3], you can replicate these tests on your own Flame device using `make test-perf` and have JSON output to your console containing results. If you are feeling especially proactive, you can even use this to test your patches before landing to see if they will cause performance regressions. *What is the goal of this?* By using the data displayed in Datazilla, the goal is for all app engineers to be conscious about the performance of their applications and be proactive about quickly finding problems and resolving them once a regression occurs. There is also the goal for each application to be able to complete this event within 1000ms [4]. If you have any questions about these changes, further details, how to use it, their benefits, or any other questions, feel free to reach out to me and I'll be happy to help. You can also view my presentation of the basis of these changes from last week's Gaia weekly recording [5]. Thanks! [1] https://bugzilla.mozilla.org/show_bug.cgi?id=996038 [2] https://developer.mozilla.org/en-US/Apps/Build/Performance/Firefox_OS_app_responsiveness_guidelines#Implementation [3] https://developer.mozilla.org/en-US/Firefox_OS/Platform/Automated_testing/Gaia_performance_tests [4] https://wiki.mozilla.org/FirefoxOS/Performance/Release_Acceptance [5] http://mzl.la/1mGexKb *Eli Perelman* Software Engineer, Firefox OS
_______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
