Firefox OS/Performance/Tools/Data Sources and Tools for FxOS Perfomance Optimization
Good performance data is necessary for developers to optimize, debug regressions, and to learn the best practices for developing on our platform. Therefore it is essential that the Firefox OS Performance team take a look at all of the available performance related data to identify what we have to work with right now and what other performance data we should work to expose in the future.
Performance Data Sources
Below is a list of all of the performance data sources we would like to expose to app developers to help with optimization.
- Global memory usage.
- Per-process memory usage broken down into USS, RSS, JS objects, etc.
- GC events.
- Any relavent GC stats (e.g. how much memory is each generation group).
- OOM pressure events.
- OOM killer nice adjustment events.
- Main thread stalls (i.e. jank).
- App startup sequence events.
- Arbitrary "debug" events from content JS.
- I/O events (e.g. file load start, file load end).
- Network utilization (upload and download).
- JS parse start and end.
- JS JIT start and end, both baseline and ion.
- JS JIT bailouts.
- JS JIT warnings/errors (i.e. JS code from line X to Y has unstable type flow).
- JS IC invalidations.
- Globals objects mutation events and what is mutating the object. (Useful for debugging improper global state mutation bugs).
- JS function execution tracing.
- Layering data.
- Reflow events.
- GPU memory information.
- Frame rate.
- Frame uniformity (i.e. project butter).
- Vsync events.
- Power consumption (voltage and amperage over time).
- Rotation events.
- Device Motion Data.
- GPS status.
- GPS coordinates.
- Bluetooth events.
- USB events.
- Touch event latency.
- Touch events.
- RIL events.
- Telephone or Data Call start latency.
- WebRTC video and audio statistics.
Currently, Firefox OS posesses the ability to report out a number of performance related statistics in realtime. Figure 1 illustrates the current organization of the data gathering and expropriation.
The data is gathered by a set of observers that watch for events/changes in their respective performance areas and then report the changed stats via the observe message system. The sampling profiler and the child process actors set up observers to receive these events. The other main source of data is the memory sub-system which is polled by both the profiler and child actors to get memory statistics for each process.
The child process actors handle sending all of the performance data to the parent process actors which forward the data over the remote debugging protocol to the connected host PC.