Closed Bug 1206117 Opened 9 years ago Closed 7 months ago

Make Telemetry Histograms.json "build faster" friendly


(Toolkit :: Telemetry, defect, P4)






(Reporter: nalexander, Unassigned)



(Whiteboard: [measurement:client])

Right now, Telemetry is a compiled component.  That means that "build faster" type of builds based on --disable-compile-environment -- like Fennec's |mach artificat| based build (Bug 1162191 and friends), and glandium's proposal in -- will have a hard time adding Telemetry.  That's unfortunate.

This ticket is to track making (part of) Telemetry extensible without requiring a compile environment.  I expect there to be a long history of hard performance requirements and C++ and JS accessibility that inform the current solution; I'd like to understand what it would look like to make at least part of Histograms.json run-time defined.
bsmedberg, gfritzsche: perhaps one of you could provide some history and explain what problems we might see if we try to make some parts of Telemetry defined at run time?  We already have support for add-on defined Telemetry probes, so perhaps this functionality already exists and just needs some in-tree build support?

glandium, gps, mfinkle, rhelmer, rnewman: just raising this as a "build faster" sub-ticket.
Flags: needinfo?(gfritzsche)
Flags: needinfo?(benjamin)
Here are some of the complications:

* privacy reviews and documentation - we want to be able to list explicitly the data we're collecting, and have confidence that it is well-owned, expires, etc. See bug 1194287 for doc stuff.
* server components: the telemetry server uses the histogram definitions to drive the dashboards.
* parsing JSON at runtime harms startup times, so we definitely don't want to do that.

It will be a fun challange to to go faster while still being able to explicitly list/document the piece sof data that we collect and drive the server-side reporting.
Flags: needinfo?(gfritzsche)
Flags: needinfo?(benjamin)
Making new Telemetry probes available with artifact builds would have performance implications, i don't think we'll generally do that.

We are gradually working towards supporting faster builds though, by making it feasible to split up registry files (and build impact) across the tree.
Given the current work this will still take a while.
Priority: -- → P4
Whiteboard: [measurement:client]
See Also: → 1425909
Severity: normal → S3

bug 1425909 for scalar support, bug 1448945 for events support.

Closed: 7 months ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.