1927146 - Teach `Parent` instances of the LabeledMemoryDistribution Metric what their label is.

Status: RESOLVED WONTFIX

(Toolkit :: Telemetry, task, P2)

Description

[Adam Brouwers-Harries [:aabh] [he/him] ⌚GMT]

The from_glean_metric method for a LabeledMemoryDistribution teaches a Child instance what the label is, but does not do this for the Parent instance: https://searchfox.org/mozilla-central/source/toolkit/components/glean/api/src/private/labeled.rs#143

This makes it hard for us to add a useful labeled marker in operations on a Labeled Parent instance, as we do not have access to the label. This method should do the same thing for the parent that it does for the child, and the Parent type should be updated accordingly to include the label.

Comment 1

[Chris H-C :chutten]

We're gonna chat about this and related topics next week, but the present position is thus:

• FOG, by its nature of being everywhere and used by everything often quite a lot, is under perf scrutiny
• Constructing and keeping copies of strings, even limited to 16 or 100 per metric depending whether they're known at compile-time is liable to get us in trouble if we do it for too many metrics. And though we're not unused to being in trouble, we try to limit it to costs that are necessary to be borne.
• The labels are stored in the SDK, but not in an easy-to-extract way. If we could simply reference those necessary bytes, I think we'd satisfy most uses. ( If we guarantee nul-termination, we might even satisfy bonus uses like FFI or bug 1892465 )
• Refactoring those bytes to be referenceable might be work that intersects with bug 1855172's goal of metric identifier (sub)string optimization.

Comment 2

[Adam Brouwers-Harries [:aabh] [he/him] ⌚GMT]

Based on our chat this week, I think it might be reasonable to close this issue as wontfix, and open a new meta bug for the solution that we proposed. In other words:

• Fixing Bug 1927580
• Modifying the way in which we store __glean_metric_maps so that we can use the information exposed in Bug 1927580 and look up a metric from the id and sub-metric id.
• Add method to core Glean API (on MetricType) to get information about a metric instance in such a way that the profiler can use it at streaming time.

This is all parent-process work, as for child processes we already have access to the label (and we cannot have dynamic child labels).

Additionally, I am going to open a bug to consider modifying how Glean stores the static strings for labels and metric names in Rust code. If we can move them around a bit, we might be able to both reduce the size of the XUL binary a little (through de-duplication), and have them statically accessible from both parent and child processes.

Thoughts @chutten?

Comment 3

[Chris H-C :chutten]

(In reply to Adam Brouwers-Harries [:aabh] [he/him] ⌚GMT from comment #2)

This is all parent-process work, as for child processes we already have access to the label (and we cannot have dynamic child labels).

(we totally can, FOG just stores it regardless of whether glean-core will convert it to __other__)

Thoughts @chutten?

Sounds like a solid plan to me.