Re: [w3ctag/design-reviews] JS Self-Profiling API (#366)

Thank you for the feedback!

> We both think that, even if doing the compression for sending is a little difficult right now, that's a platform gap that's likely to be fixed in the relatively near future [...]

Yes! The work on stream-based compression will complement this excellently.

> > Additionally, it would be great to get feedback on whether or not we should set a maximum sample count for each profiler, or maximum trace duration. The latter seems easier to reason about.
>
> I don't think we have thoughts on this -- but maybe we would if you described what the advantages and disadvantages were a little more clearly.

We ended up going for a sample count maximum in the latest proposal, for the reasons that memory usage and ingestion pipelines are likely to be more sensitive to the number of samples rather than the duration of time spent during sampling (especially with a low sample rate).

> One additional issue is that @kenchris was concerned about was what the effects on the users randomly chosen for this sort of profiling would be -- it seems like it could have a serious effect on their battery life, etc. (On the flip side, many web features can use a lot of battery life.)

That would depend pretty heavily on the VM's architecture, as well as the sample intervals the user agent chooses to support. IIRC, in V8 we're seeing about ~4% of CPU cycles spent during sampling with a 10ms sample rate.

One note of interest- @toddreifsteck mentioned at the TPAC Web Perf F2F that they had achieved a 1% overhead in Chakra's sampling profiler with a 1ms sample rate.

> BTW, one concern I heard from colleagues is that they'd like to avoid content depending on what stack frames look like (which is already apparently a problem with Error.stack) since they'd like to be able to change/improve that over time.

Recently the spec has been updated to require that traces return the ECMA-262 defined "name" property of function objects after some feedback for more rigorous specification from implementors. These are fairly well-specified, although lack some detail for object members.

In practice, I don't suspect that the function names returned by traces will be terribly useful- more often than not, they'll likely be unminified via sourcemaps on the server, and used as a backup when sourcemap lookup fails.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/366#issuecomment-537345340