Question on creating a stable alternative to Node->DebugName()

[Jack Franklin]

Hello,

I was sent your way after my CL crrev.com/c/6625582 to ask a question about a proposed small bit of refactoring I'd like to do.

Context

I work on Performance Tooling in DevTools and we consume trace events from a Chrome trace to build UIs like the DevTools Performance Panel.

Recently, I've been adding `nodeName` fields to a number of these trace events and populating it with the value of Node::DebugName() [source].

In the CL above, @Nico Weber  left this comment: 

> (Also, "DebugName()" isn't stable and not meant to be used for anything but debugging. I'm assuming it's not used for anything that would make it hard to change the DebugName of something later, yes?)

Proposal / question

Longer term I would like to start work on presenting these node names in our UI in a more structured, formatted way for our users, so the exact format of what DebugName() currently returns is going to become important for us; at this point I think we are moving away from the use that DebugName() was initially designed for.

Is there any strong opinions on implementing an alternative to DebugName() called something like NodeNameForTrace() (or similar) which can be a version that is sensitive to changes, leaving DebugName() open for just its original intentions?

Thanks,

Jack.

[Michael Lippautz]

We already have NameClient which can be used to override GetHumanReadableName(). Anything that's ScriptWrappable (so Node as well) already sets this to the JS interface name.

This infrastructure is used by DevTools heap snapshot to provide C++ objects in the object graph with, well, human readable names.  NameClient itself is used for (subjectively) "interesting" objects that users could be interested in.

Is this a fit? 

-Michael

[Stephen Nusko]

Another potential route here is have you thought about proto I.E. typed trace arguments? They come with the benefit of being backed by protos which have a very good versioning story. In addition, regardless of if you used typed or stick with debugArguments on traces you could add a trace processor browser test and ensure that no one changes the names on you (a test would fail).

For typed arguments if your object provides a WriteIntoTrace method you can then very easily do things like `TRACE_EVENT("MyCat", "myTraceEventName", MyProtoClass, my_object_ref);` (there is also WriteIntoTracedValue if you prefer a more json like way, but this ends up being DebugArguments if I recall correctly). Here is an example of WriteIntoTrace in action.

The UI supports displaying protos in a nice format and is queryable in perfetto's sql language (although my understanding is devtools consumes only json so probably isn't helpful to you at the moment). I do believe by default args get exported when converting to json, which would also let you rely on the format.

Just a couple thoughts,

Stephen

--
You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to platform-architect...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CAH%2BmL5D-sAB8inFLsW7THwyMNMZ60V48it1vrcn1GnvrHH0aHg%40mail.gmail.com.

[Jack Franklin]

Hi both,

Thank you for your input and suggestions.

I tried `HumanReadableName`, but this is what is used to define that (e.g.) images are referred to as `HTMLImageElement`. In this case, the DebugName() output of `img id="foo"` is preferred.

Therefore, I will look next into the `WriteIntoTrace` approach, which seems like it could be a fit, if we defined that on HTML Nodes and made it generate something that looks like what DebugName() currently outputs.

Thanks,

Jack.