1640995 - Audit PROFILER_MARKER_TEXT's, and convert them to structured data

Status: NEW

(Core :: Gecko Profiler, task, P2)

Description

[Greg Tatum [:gregtatum]]

Right now the data payloads have been created in an ad hoc fashion, or worse, the information is packed into the name of the marker. Timing information is usually duplicated, and we don't surface all of the information. In addition, we can leak PII in the raw text.

Here is an example of an unstructured marker:

{
  "name": "Non-blank paint after 2359ms for URL https://en.wikipedia.org/wiki/Barack_Obama, foreground tab",
  "time": 9051516.478496548,
  "data": null
}

https://searchfox.org/mozilla-central/rev/7dafc35406b9c945189c617d427f5458933fd3fb/dom/base/nsDOMNavigationTiming.cpp#396

We should convert these into structured payloads using marker the new schema. These would be good candidates for some kind of printf-like format.

Comment 1

[Gerald Squelart (he/him) (not at Mozilla since 2022-09-15)]

TextMarkerPayload has been removed, in favor of PROFILER_MARKER_TEXT and the TextMarker type.
But this bug remains useful, as some text markers could really be their own type with a more meaningful payload than a printf'd string.

Comment 2

[Gerald Squelart (he/him) (not at Mozilla since 2022-09-15)]

Thought:

Creating new marker types is fairly easy, but still quite a bit of work: The smallest one, with only a name and no extra data, takes at least 13 lines, e.g., ContentFrameMarker -- it could be a bit smaller, at the loss of some clarity.
This means that in lots of situations where the developer wants to quickly add simple and one-shot markers, they may be tempted to just use a one-line PROFILER_MARKER_TEXT and be done with it.

So as part of this bug, I would suggest that we first make a survey of existing text markers, and investigate how they could be converted to bespoke marker types in a simpler way.

Some random ideas:

• Macro helper(s) to handle marker type definition boilerplate.
• printf-like function (or C++20 std::format), where the format string encodes the schema information.
• std::ostream-like style, where marker schema and data are appended with << and special types.
• Variadic function with special types to encode schema information.