Discussing a potential performance.isProfiling() method

[rubennorte]

Hi everyone,

I'm not sure this is the right place to bring this up, apologies if it isn't.

General tracing APIs like Trace on Android have methods to determine if the app is currently being traced/profiled, in order to avoid potentially expensive work when it isn't. I see there is no observability for this on Web, outside of things like Chrome extensions via chrome.devtools.performance.onProfilingStarted.

Have there been any discussions about bringing this to the Web via a standard method (e.g.: performance.isProfiling() or console.isProfiling()) so it can be used before calling performance.measure or console.timeStamp with expensive arguments?

For context, I'm an engineer on the React Native team working on performance and this is something I would like to bring to the framework, aligning with Web specs if possible.

Thanks!

[mmocny]

Potentially related past conversations:

• Add a non-normative format for the detail param that allows developers to customize the presentation of timings in devtools user-timing#111
• [LoAF] Allow for annotations for long animation frame to further help debugging long-animation-frames#3
• Add a standard track/category field to the spec user-timing#109
• Allow marks and measures to be shown in developer tooling without adding it to the performance timeline user-timing#68
• (more?)

...which all basically related to "efficiently" annotating tracing.

(Side note, we might be able to triage and close some of these...)

[rubennorte]

@mmocny thanks for the references!

This issue assumes that we already have relatively low cost methods to trace, like console.timeStamp. What would be interesting would be having a way to know if we're current tracing or hooks to be notified when tracing starts/stops. That would allow to avoid potentially expensive set up that would only be useful for tracing.

I wonder if the reason this doesn't exist is main for lack of interest, or more about things like privacy concerns.

[yoavweiss]

@rubennorte - I'd love to better understand the use case!

Who is starting the trace here? Why can't they install an extension that uses the extension API (and communicates the tracing state to the DOM/main-world somehow)?

My main concern with this would be e.g. 3Ps that are doing shady things and hiding them when tracing is enabled, to avoid detection.

[rubennorte]

Thanks for you reply, @yoavweiss !

@rubennorte - I'd love to better understand the use case!

Who is starting the trace here? Why can't they install an extension that uses the extension API (and communicates the tracing state to the DOM/main-world somehow)?

In this case it'd just be any developer using DevTools. This would be intended for app developers and library authors to apply behaviors based on the profiling state. For example, we have a use case in React Native where we generally disable LogBox (an in-app debugging overlay) during tracing to avoid debugging logic affecting app orchestration / measurements.

My main concern with this would be e.g. 3Ps that are doing shady things and hiding them when tracing is enabled, to avoid detection.

This seems completely fair, and I'd understand it could be a valid reason not to provide this functionality. Any ideas on how this could be mitigated?

[yoavweiss]

This seems completely fair, and I'd understand it could be a valid reason not to provide this functionality. Any ideas on how this could be mitigated?

Maybe an off-by-default permission policy can enable sites to opt into allowing this functionality. Or a dev tools settings that requires developers to opt-in specific scripts to have that API return the right values?