Intent to Implement: JS Self-Profiling API

[Andrew Comminos]

Contact emails

acom...@fb.com, tdre...@chromium.org

Explainer

https://www.github.com/WICG/js-self-profiling

Design doc/Spec

Design doc: https://docs.google.com/document/d/1NGrU6xVWHq8uLfSFRfDWh1v_UiXLiOgr2FDb2KIaoL0

Tag review: https://github.com/w3ctag/design-reviews/issues/366

Summary

A web-exposed sampling profiler for measuring client JavaScript execution time.

Motivation

Currently, it is difficult for web developers to understand how their applications perform in the wide variety of conditions encountered on real user devices.

A native self-profiling API for JS code would also allow web developers to efficiently find hotspots in their JS code during page loads and user interactions, to assign CPU budgets to individual JS-implemented features on the page, to find unnecessary work being done on the client, and to find low-priority JS code executing in the background and wasting device power.

Risks

Interoperability and Compatibility

As a performance measurement API, the compatibility risk is low. Other browsers such as Firefox and Safari ship similar profilers that may be augmented to be web-exposed.

Edge: No signals

Firefox: No signals

Safari: No signals

Web / Framework developers: Positive (Facebook, Boomerang, Dropbox)

Ergonomics

This API is likely to be used with the existing family of performance timeline APIs.

The largest concern with exposing a sampling profiler to the web is reducing the performance of the page if profiling is enabled indiscriminately. As the UA has freedom to choose which sampling intervals it supports, the only mandatory overhead required is symbolication.

Activation

To leverage the tracing data effectively, a web service to ingest and aggregate traces is useful for analysis. Facebook intends to contribute an open-source reference web service, as well as a client-side polyfill for the API to trace page loads and other interactions.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes, for all platforms except Android. This is due to the lack of Site Isolation, as the API exposes a high-resolution timing source (in the form of sample timestamps).

Link to entry on the feature dashboard

https://chromestatus.com/feature/5170190448852992

Requesting approval to ship?

No.

[rek...@gmail.com]

I'm curious if developers will ever be able to profile their own things, ever again? Is performance.now() ever going to be useful again? Or will the spectre mitigations forever keep us from doing any useful timing analysis of our own work?

[Steve Nothover]

I saw a stop() but no start() method.  I realize that his is likely not the right place to comment.

Steve

On Sunday, April 28, 2019 at 9:58:46 PM UTC-4, Andrew Comminos wrote:

Contact emails

xxxxxx

[Martin Šrámek]

Hey Tim,

Per https://www.chromium.org/blink/launching-features, would you mind also driving this through the Chrome internal launch process, so we can look at the implications of adding new timers?

Thanks,

Martin

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1bbcbc3b-22e0-45e9-a9c8-69b15a6718d9%40chromium.org.