You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While serializing the JSON might be okay for small profiles, it seems risky to encourage it as a general solution. Would it be better to provide the profile as serialized JSON already, potentially removing some blocking work from the main thread? It's not unlikely that those data structures wouldn't have to exist in the JS heap at any point in time.
The text was updated successfully, but these errors were encountered:
Thinking out loud, one could transfer the trace to a worker and serialize+beacon it there. Especially seems preferred if you want to add in a CompressionStream.
Since you mentioned CompressionStream (and this is WICG, not raw JS), maybe the result of calling profiler.stop() could follow Response precedent and offer both .json(): Promise<TraceData> and .stream() (like res.body, for direct use in a compression stream)? Having the data in the main thread JS heap + transferring could still be a noticeable cost but having .stream() seems to also allow easy transfer to a separate worker thread.
From the current examples:
While serializing the JSON might be okay for small profiles, it seems risky to encourage it as a general solution. Would it be better to provide the profile as serialized JSON already, potentially removing some blocking work from the main thread? It's not unlikely that those data structures wouldn't have to exist in the JS heap at any point in time.
The text was updated successfully, but these errors were encountered: