1393617 - Expose a safe same-origin profiler API to the web

Status: NEW

(Core :: Performance, enhancement, P3)

Description

[Benoit Girard (:BenWa)]

Just like browsers, websites want to optimize and tune using real world data. If websites could profile themselves then they could collect that data and prioritize performance work better.

Keep in mind that this is data that websites can already get, just not well. Website can already wrap their same-origin-script functions with performance.now() wrappers. So while this is something that attacks can use around platforms operations they want to time, it's not something a real sites can use because it doesn't scale to a large code base.

If an API like this was exposed to the web, websites could aggregate the data (themselves or using a middleware) and prioritize impactful performance work and identify outliers.

Here's a very rough idea for an API:

// Returns a list of profiling features that can be used later.
// NOTE: Both Firefox and Chrome tracing allows the user to
// select data to be collected to control the perf impact and size.
Performance.profiler.getProfilingFeatures();

// Start profiling, including previously queried features.
// Browser profiler might have a non blocking async startup phase
// like starting a sampling thread or require IPC message. It should
// return a promise to notify the user that sampling has started.
// Promise can be rejected if the profiler is a singleton that is already
// being used or other consideration where profiler is forbidden.
Performance.profiler.start(featureListAndOptions): returns Promise

// Returns the profile, promise for async saving
Performance.profiler.stop(): returns Promise


Would need to figure out which format or if the format is left to the implementor. I'm leaning towards the latter for now. Both V8/SpiderMonkey have a sampling profiler but I don't think it's a great idea to limit what tools can do if we lock in a format. It would be pretty easy for middleware/JS libraries to deal with these formats anyways.

Comment 1

[Benoit Girard (:BenWa)]

There's a WICG discussion that has been started for this idea:
https://discourse.wicg.io/t/proposal-an-api-to-allow-webpage-javascript-to-profile-its-own-performance/2818

and an explainer:
https://github.com/vdjeric/js-self-profiling

Feedback and support from Mozilla would be greatly appreciated.

Comment 2

[Randell Jesup [:jesup] (needinfo me)]

Thanks Benoit; we're looking at them.  I've read over all of it and registered for the WICG discourse a couple of days ago.

We'll need to figure out what exactly would be exposed, what happens when other origins are present in a stack trace, the overhead to collect this, and also the spectre implications -- it's possible due to the implicit exposure of timing information that we might have to delay this for project Fission (site isolation), and/or degrade/fuzz the sampling (as mentioned a bit in Vlad's github).

Comment 3

[Benoit Girard (:BenWa)]

Great. Please give us feedback if we could draft a spec in a way that would allow Gecko to support this spec without site isolation. Otherwise at the very least we want to get a spec that Gecko would ship once site isolation is ready.

Comment 4

[Boris Zbarsky [:bzbarsky]]

https://github.com/mozilla/standards-positions/issues/92 is probably the right venue for the moment.

Comment 6

[Olli Pettay [:smaug][[e-mail]]]

(Performance team has been dealing with the performance APIs)