Using a circular buffer instead of stopping/starting profiling

[mbkv]

I recently started experimenting with this API at Kapwing, a modern browser based video editor. We’ve had great success using this to implement a reporting system. We’ve even fixed several bugs within hours of deploying it. Thank you to everyone involved!

The one thing in the spec that confused me is the incredibly short lifetime of Profiler. While I think I understand the reasoning behind this decision, it is also a little confusing. As a user of this API, I would have heavily preferred for Profiler to contain a circular buffer of the previous “maxBufferSize” samples. That way, when we detect a degradation in performance, we can stop the recording, and immediately push it offline for analysis

The current spec however forces us to keep a copy of the previous trace, just in case we need to concatenate them manually. It also generates a lot more garbage than is necessary as there’s no way to predict ahead of time if this trace will end up being “useful”. IE we may decide to issue a report in the 2 seconds after a trace ends. We would not have the the context clues if we just decide to throw away the previous Profiler instance

I’m wondering if this alternative was considered, or if there was a browser limitation that stops this?

[JonasBa]

@mbkv I think the idea is to always perform offline analysis. Would you mind explaining a bit as to why this is something you'd want to perform on the client?

It seems like it should be possible to implement this with the current state of the API by storing the stack samples in a ring buffer of your own. Did you manage to achieve that or is this mostly about having the API do that for you?

[mbkv]

Sure! Before the trace even reaches even reaches our servers. We decide whether or not this trace would even be useful on the client side. The vast majority of traces would be more or less uninteresting, have low impact, and not worth looking into. But roughly the idea is that whether or not we detect something is wrong, IE, redux taking too long to run, react taking too long to render, we would immediately submit a report for an engineer to look at offline. We found this method fairly useful and will plan on scaling this up to something like detecting slow user interaction speed and bad framerate

Did you manage to achieve that or is this mostly about having the API do that for you?

I wouldn't call our implementation a ring buffer, but yes we just keep around the current trace and the last trace, and just combine the traces in a web worker before we submit. It is definitely possible to do but it feels like something the API should cover