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

@kenchris and I are looking at this in a breakout at our Tokyo face-to-face.

First thought:
> I'd be interested in feedback on whether we should work on optimizing a structurally compressed JS object profile format, or allow traces to be returned GZIP'd in an ArrayBuffer. The latter is much more viable for transmission over the wire, but harder to work with on the client side. 

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 (through work in or related to the WHATWG Streams spec, like the work discussed in w3ctag/design-reviews#410), so it's probably better to do the easy-to-use thing, with the knowledge that being able to do compression in client JS should become easier pretty soon.

> 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.


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.)  It's something worth thinking about, though probably not a blocking issue.  (Should there be any interactions with, say, battery saver mode?  Though if there were that might pose privacy concerns.)

-- 
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-530659259