1355649 - [meta] Unify Gecko's performance data sources

Status: NEW

(Core :: Gecko Profiler, enhancement, P3)

Description

[Jim Blandy :jimb]

It should be easy for a developer who is familiar with some component of Firefox (graphics, or networking, say) to add performance measurements that can be immediately visualized in the perf.html profiler UI, without needing to be familiar with devtools code.

Call this hypothetical developer "Dev".

# Off-the shelf control, enumeration, and documentation

Gecko should provide a common registry for enabling data sources, so that Dev need not write yet another environment variable parser, JavaScript function in js/src/builtin/TestingFunctions.cpp, WebIDL API, and Gecko Profiler add-on patch to turn the data source on and off.

The registry should be tree-structured, to allow different teams to add any number of measurements for their own component without distracting other teams by cluttering a common list with mysterious details.

Adding a simple, on-off data source to the registry should require little effort, but the design should permit incremental addition of parameters, tooltip-style summaries, documentation URLs, natural language labels, and so on.

# Off-the-shelf visualization and analysis

If a new measurement contributes its results to the common performance data queue, it should be immediately visible in perf.html or other developer tools, and immediately available in serialized form. Dev should have no need to modify the perf.html sources or write another JSON serializer.

To this end, queue entries should provide enough metadata about themselves to allow tools like perf.html to plot them in a generic way, and to allow reasonable serialization. Most of the performance data sources in Gecko now actually collect only a few general forms of data: start times and end times, labels, stacks, and perhaps edges from one event to another. So this should be feasible.

# Performance data for foundational layers

The common performance queue should be available to the SpiderMonkey stand-alone shell and other low-level parts of the system. It should avoid dependencies on higher levels of the system like the JSAPI or WebIDL.

# Consolidated existing sources

The Gecko platform has more than a dozen different facilities for collecting and logging performance data, each with its own methods of control, its own serialization format, and its own analysis tools. Some of these clearly need purpose-built interaces, but many can be adapted to participate in the common performance queue and registry.

# Ease of adding new sources

If Dev's needs are simple or commonplace enough, it should require little effort to add a new performance source that fully participates in the common registry, queueing, and visualization tools.