WICG
binary layout + code markers
Awesome work that is quite palatable to us as well (e.g Dropbox). A few random notes:
-
Do you guys have more details on a potential binary layout and its implications in terms of downstream aggregation/indexing (in our case we opted for byte frames allowing for direct skip-list indexing without pre-parsing).
-
Are we considering the option of having codepath markers injected in the trace? Typically some on/off markers injected via annotation and expressing specific properties for a given code path? The primary consumer for those would be a backend aggregator. Another application of this apparatus would be to infer sampling density based on annotation (typically for flows known to involve higher complexity such as more promises, threads, etc.).
@opaugam We're working on the binary format now. Could you share details of your use case? Could you go into more detail about "byte frames"?
Trace markers would be useful; I think @acomminos' TPAC 2018 presentation brought this up, mentioning that if the time base is the same as performance.mark you could just join with that. I couldn't find meeting minutes anywhere :/ Andrew, what was the reaction to marks?
Edit: TPAC 2018 Web Perf WG Minutes courtesy of Andrew. Some relevant commentary about performance concerns, threading, and an efficient format for upload being the primary use case.
@dominiccooney, the consensus was that it was redundant since (as you mentioned) the time origins are the same. While it's a bit awkward, I do think we should leverage as much functionality from the resource timeline APIs as possible. As long as the trace data joining story is good, I don't think it'll be too bad.
It would be cool to have captured markers/measures/etc be present in the profiler's trace payload for convenience, but it'd be quite heavyweight from a spec perspective considering we'd have to define a binary format for those (that could easily go out of sync with new levels).
