DNSRequestChild's constructor takes `const nsCString&` parameters. If
you have a `const nsACString&` argument to pass in to the constructor,
you're forced to construct a temporary nsCString object to satisfy the
prototype. But the temporary string will just get copied inside the
constructor and you'll have to destroy the temporary string object you
created.
Let's skip all this, and just have DNSRequestChild take `const
nsACString&` arguments instead, and avoid the temporary object.
The code for serializing an EventKey in SerializeEventsArray does
something peculiar: it creates a temporary array of nsCStrings, copies
the appropriate strings from the event info for the key, and then
converts those into JavaScript strings. But we shouldn't need to do any
copying into the temporary array. We can do everything directly on the
strings from the event info themselves.
It seemed best to introduce a ToJSString for this purpose, which comes
in handy in a couple other places as well.
Once we've created the array of events for a given process, there's no
need to copy it in the array for all process events. We can Move() it
instead, which is more efficient.
When constructing DynamicEventInfo, we can require the extra keys to be
passed in by rvalue reference, rather than copying the entire array.
When registering dynamic events, we also don't need to construct an
entirely new nsCString to pass to the constructor; we can simply pass
the nsACString reference we received and go from there.
These methods are returning nsCString wrappers for static char arrays;
we only need to return nsDependentCStrings, rather than allocating and
copying entirely new nsCString objects.
To cut down on complexity, we don't require specifying any expiry versions.
Given that these events will be recorded non-persistently from off-train add-ons, they can be expired by shipping new add-on releases.
We also start to use the new "record on release" terminology here instead of opt-in/opt-out, but are not changing the internal functionality yet.
Technically, this is implemented by keeping a separate registry for the dynamic event information.
Built-in & dynamic events are tracked with separate numeric ids, so introduce a common identifier for both, an EventKey.
For actual event storage, the events are treated the same as built-in events. They are simply bucketed into the 'dynamic' process storage.
This approach ends up duplicating code paths that use the event info, but keeps a single implementation for recording, storage & serialization.
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.
TimeStamp::ProcessCreations()'s aIsInconsistent outparam is ignored by the
majority of its caller. This patch makes it optional. Notably, this makes
ProcessCreation() easier to use in a constructor's initializer list.
