1047118 - Mechanisms to capture boot timings

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Performance, defect, P2)

Description

[jbailey]

Find the means through which timing information (since boot) will be collected for various stages of boot.

The stages for which we desire to collect timing information right now are roughly:
- init : Entry into user-space from linux kernel. Gives timing of kernel initialization.
- b2g.sh : Entry point to gecko - Gives time init takes running startup scripts.
- shell.html : Gives timing of gecko execution.
- System app : Time spent going from gecko to gaia side of system app.
- Homescreen : The time until the boot sequence is complete, from the users perspective.

This information is easy to access in the first two stages, but the rest require more thought.

Comment 1

[jbailey]

The current approach being taken is to record the earlier pieces (before b2g) on the file system temporarily, to be grabbed by the test scripts, and then for the later stages to record timing information within themselves (predicated on a setting or something). After which, a marionette test would fire events requesting this information be reported back.

Comment 2

[jbailey]

Due to the nature of this change, a few different areas of code have been added to. 
As such, each will be separated into its own bug for review. 

Overall, instrumentation was added to: system/core (1058811), gonk-misc (1058810), gecko/b2g/chrome (1058817), system app, verticalhome app.

The marionette test that consumes this data (1058843) will be in gaia/tests/performance/.

The flow of data proceeds as follows:
1.) Init gets uptime once it begins, and stores it into an android property
2.) b2g.sh stores the android property and current time in a json file (alternatively should we store the entire json object into another property?)
3.) shell, system, and home-screen each record key data points as part of their execution.
4.) After boot, Marionette test retrieves the stored information from step 2 via adb, and step 3 through the marionette client.

Since data is collected after the fact, there is expected to be minimal performance impact.

Possible further steps:
Gate the data collection behind a setting, or only on debug builds.

Comment 3

[Bobby Chien]

Implemented by Raptor [1] since v2.5. Also could refer to Raptor dashboard [2] for statistics. 

[1] https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_OS/Automated_testing/Raptor
[2] https://raptor.mozilla.org/

Comment 4

[BMO Automation]

Firefox OS is not being worked on