Since LinearHistogram and its descendants inherit ranges_ from
Histogram, and we wanted to replace the copying into a std::vec
for Histogram, the simplest approach seemed to just be to
precompute ranges for all histograms, exponential or otherwise.
This should have the added benefit of reducing the memory
footprint for those histograms, since they will benefit from the
deduplication work that the precomputing script already does.
MozReview-Commit-ID: JTV5Dej5ZIb
Switch from static multi-dimensional arrays to dynamic one-dimensional arrays
that are only allocated in the parent process.
MozReview-Commit-ID: tyGEFhU2Fq
Switch from static multi-dimensional arrays to dynamic one-dimensional arrays
that are only allocated in the parent process.
MozReview-Commit-ID: tyGEFhU2Fq
With the removal of the old addonHistograms, all histograms are now registered.
So removing registered(Keyed)Histograms should be straightforward?
Unfortunately not, as this was how we filtered data based on dataset
(opt-in/opt-out), so a little more fiddling was needed to get C++ to only
serialize dataset-appropriate data (instead of post-facto filtering it in JS).
MozReview-Commit-ID: HDplhmzmzJl
The log and exp calls in base::Histogram::InitializeBucketRange()
were showing up in profiles. This patch uses the precomputed
buckets for exponential histograms instead of computing them at
runtime. Though linear histograms do show up in the profile that
prompted this change, they contribute much less, and due to the
trivial nature of generating these, it's unlikely that a static
cache would provide much if any speedup.
MozReview-Commit-ID: IavFwoWjFhk
The log and exp calls in base::Histogram::InitializeBucketRange()
were showing up in profiles. This patch uses the precomputed
buckets for exponential histograms instead of computing them at
runtime. Though linear histograms do show up in the profile that
prompted this change, they contribute much less, and due to the
trivial nature of generating these, it's unlikely that a static
cache would provide much if any speedup.
MozReview-Commit-ID: IavFwoWjFhk
Previously we assumed count histograms were always present in payloads.
This was an erroneous assumption as count histograms were only 0 if they were
session histograms, or if they were from subsession histograms from subsessions
_after_ a subsession when they held a non-0 value.
So let's just treat count histograms as normal histograms from now on, without
any of this "sometimes 0" nonsense. This simplifies the code, tests, and our
understanding... and _should_ have few/zero downstream effects since the
existing behaviour was so poorly-understood (though exactly tested).
MozReview-Commit-ID: BH108ksygGw
TelemetrySession's getKeyedHistograms asks for each keyed histogram
individually. This is inefficient and doesn't work well with the storage
refactor.
So, plumb through a subsession keyed histogram snapshot API and convert
TelemetrySession over to using it.
MozReview-Commit-ID: Af9dTqw99UA
Previously we were doing bad string manipulation nonsense. Now when asked for
snapshots C++ can return a properly-formated Object tree.
MozReview-Commit-ID: HAvIbgzUvMU
Previously we used the base::StatisticsRecorder object for storage by name.
This is keyed by histogram name, which doesn't match our storage reality anymore.
Instead we use a name to refer to a set of histogram instances that record data from different processes, as well as separating session and subsession data.
In this re-write, we instead introduce the following lookup paths (managed in TelemetryHistogram.cpp):
- Main storage:
- (histogramId, processId, sessionOrSubsession) -> Histogram*
- (histogramId, processId) -> KeyedHistogram* (this handles subsessions internally)
- Lookup:
- (histogramName) -> histogramId
- (HistogramID) -> bool (is recording enabled for this histogram?)
This is wrapped with a few lookup functions.
This also allows us to keep HistogramIDs in the JS histogram instances now, instead of pointers to Histogram instances.
That means Histogram instance life-time management is now properly contained inside TelemetryHistogram.cpp.
MozReview-Commit-ID: 5yijGv7mc89
The Chromium IPC histogram code used the StatisticsRecorder object for storage.
This is keyed by histogram name, which doesn't match our storage reality anymore.
Instead we use a name to refer to a set of histogram instances that record data from different processes, as well as separating session and subsession data.
Consequently we need to rewrite this storage, which means StatisticsRecorder is not used anymore.
MozReview-Commit-ID: 1LC7YubpKaD
With bug 1374419 solved, static asserts in TelemetryHistogram.cpp can be improved.
Specifically, JS::gcreason::NUM_TELEMETRY_REASONS can now be compared against GC_MINOR_REASON, GC_MINOR_REASON_LONG, and GC_REASON_2 in the now constexpr gHistograms. Likewise, mozilla::StartupTimeline::MAX_EVENT_ID can be compared against STARTUP_MEASUREMENT_ERRORS.
This commit modifies the static asserts to perform these comparisons in place of ones against hardcoded values and modifies the accompanying comment to remove the TODO section.
Unfortunately it means using FLAG histograms because I need to test that their
"we have a hidden default value" behaviour is appropriately silenced as well.
MozReview-Commit-ID: J8xGXwCTRIg
Updates the core Telemetry code to use the new headers and support the extension process.
TelemetryHistogram is not cleanly refactored here; doing this uncovered a few time consuming issues with the various lookup code paths.
Updates the core Telemetry code to use the new headers and support the extension process.
TelemetryHistogram is not cleanly refactored here; doing this uncovered a few time consuming issues with the various lookup code paths.
Updates the core Telemetry code to use the new headers and support the extension process.
TelemetryHistogram is not cleanly refactored here; doing this uncovered a few time consuming issues with the various lookup code paths.
addonHistograms isn't being used and has started getting in the way.
So it goes.
Leave the "Addon Histograms" section in about:telemetry for 60 days.
Remove it in bug 1355882
MozReview-Commit-ID: 4lm7ONirofl
addonHistograms isn't being used and has started getting in the way.
So it goes.
Leave the "Addon Histograms" section in about:telemetry for 60 days.
Remove it in bug 1355882
MozReview-Commit-ID: 4lm7ONirofl
This also fixes an existing bug where we checked for the wrong type in JSKeyedHistogram_Add().
KeyedHistogram::GetHistogramType() returns one of the histogram types from nsITelemetry.idl, not one of the chromium types (base::*).
I extended the test coverage accordingly, as it seemed to be lacking.
Dropped the dataset() functions from keyed and plain histograms in file |toolkit/components/telemetry/TelemetryHistogram.cpp| to prevent their unnecessary exposure while getting histograms using the getHistogramById function (or its keyed counterpart).
Also removed the (now redundant) |internal_JSHistogram_Dataset()| and |internal_JSKeyedHistogram_Dataset()| functions from the same file and tests from the file |toolkit/components/telemetry/tests/unit/test_TelemetryHistograms.js| as the same tests are performed later on in that very file.
Changed |print("enum ID : uint32_t {", file=output)| to |print("enum HistogramID : uint32_t {", file=output)| at line 53 of the file |toolkit/components/telemetry/gen-histogram-enum.py|, and then replaced all the textual occurrences of |Telemetry::ID| to |Telemetry::HistogramID| and |ID| to |HistogramID| in 43 other files.
