Per todays discussion on the FHR/Telemetry unification concerns [0] we want to go with client-side submission of both "reset per subsession" and "old style telemetry" histograms. That means we'll have to duplicate histograms and need to investigate whether that has acceptable memory costs. 0:"Suggestions for the new unified FHR/Telemetry/Experiment ping", https://mail.mozilla.org/pipermail/fhr-dev/2015-January/thread.html#382

Dupe of bug 1126986?

Bug 1126986 seems a result of this bug. Closing as fixed per [0]: > In my Firefox 35 (release) session on Windows 7 with an uptime of 18 hours, I noted the following entries for Telemetry in about:memory: > * 1MB TelemetryFile for single-process > * This is completely unexpected, I filed bug 1126986 > * 270 kB for Telemetry heap data allocated by C++ code > * Pretty much all the Telemetry data (histograms and other data types) are stored in C++ code > * 106 kB for TelemetryPing.jsm > * 74 kB for BrowserUITelemetry.jsm > * 34 kB for TelemetryLog.jsm > * 34 kB for TelemetryStopwatch.jsm > * 29 kB for TelemetryTimestamps.jsm > * 27 kB for UITelemetry.jsm > * 23KB for TelemetryStartup.js > > The actual Telemetry ping for this session was 112 KB in uncompressed JSON form. > An 8 day session from Nightly 38 (non-E10S) on Windows 8.1 had very similar numbers. > Each process in an E10S session had roughly the same cost as the numbers above. > > I think an additional ~300KB memory overhead on desktop machines is acceptable. And: > A note on implementation: > > Measurements such as slowSQL, chrome-hangs, and thread-hangs are implemented in C++ and TelemetryPing.jsm simply queries the relevant C++ code for the measurements when creating a ping. > > We will have to modify each implementation to support two versions of the measurements (whole-session and sub-session). > We might want to report only the whole-session version of these measurements initially. [0] https://mail.mozilla.org/pipermail/fhr-dev/2015-January/thread.html#402