Add the ability to special-case DOM call labels with additional data (WebIDL profiler label frames with event names)
Categories
(Core :: Gecko Profiler, enhancement, P3)
Tracking
()
People
(Reporter: mstange, Unassigned)
References
Details
At the moment, our WebIDL code generator creates Gecko Profiler labels for WebIDL method calls (and getters and setters and constructors), using AUTO_PROFILER_LABEL_DYNAMIC_FAST. However, these profiler labels do not contain any additional data.
There are some calls that would really benefit from extra data. Examples:
ChromeUtils.importcould really use the module URL.EventTarget.dispatchEventcould use the event nameJSWindowActorChild.sendAsyncMessagecould use the message nameDocument.querySelectorAllcould use the selector string
Example profile: https://perfht.ml/2WzEXHX
At the moment, we do have the extra data for some of these in other profiler labels, but not in the ones that are shown in the JavaScript-centric call tree. We could show those in the JavaScript-centric tree by setting the RELEVANT_FOR_JS flag on these labels, but then we end up with duplicated labels: For example, we'd have ChromeUtils.import calling ChromeUtils::Import <moduleURL>.
So instead, I think we should add the ability to special-case this set of methods: The WebIDL code generator should stop emitting labels for them, and instead the called C++ code should make its profiler label RELEVANT_FOR_JS. That way, it'll be shown in the JavaScript-centric view and there will be no duplication.
Comment 1•4 years ago
|
||
(In reply to Markus Stange [:mstange] from comment #0)
So instead, I think we should add the ability to special-case this set of methods: The WebIDL code generator should stop emitting labels for them and instead the called C++ code should make its profiler label RELEVANT_FOR_JS. That way, it'll be shown in the JavaScript-centric view and there will be no duplication.
We looked at how this could be done today, and here are some information:
Currently the label frame are generated in https://searchfox.org/mozilla-central/source/dom/bindings/Codegen.py (look for AUTO_PROFILER_LABEL_DYNAMIC_FAST).
Then we have 2 possible ways to signal that we don't want to generate label frames for:
- Add a new attribute to webidl files.
- Have an hardcoded list of functions.
Hey Nika, by chance, are you the right person to ask for some feedback about this?
| Reporter | ||
Updated•4 years ago
|
Comment 2•4 years ago
|
||
I think peterv might be a better person to ask about this. I'm not super active working on WebIDL these days so I don't know the style which we'd want to use for a change like this.
I'm guessing we'll want to annotate the methods in some way to do it, which could either be done like how we do implicitJSContext (i.e. in Bindings.conf), or we could potentially do it with an extended attribute. I don't know which way is preferable though (or if the idea in general is reasonable).
Updated•4 years ago
|
Comment 3•2 years ago
|
||
Clearing the NI per the discussion with my team - unfortunately that we were unable have a quick thought on this for comment 1. Feel free to request a new NI on me, if you think we should give it a higher priority and take a closer look.
Description
•