Consider using buffered distribution APIs for FOG IPC
Categories
(Toolkit :: Telemetry, enhancement, P3)
Tracking
()
People
(Reporter: chutten, Unassigned)
References
(Blocks 1 open bug)
Details
FOG IPC stores vectors of raw samples for all the *_distribution types since at the time it was implemented there was no way to know how to bucket the samples outside of the Glean SDK itself (which was only available on the main process).
With the (experimental) buffered APIs, the bucketing behaviour and storage is now available outside of the SDK. Instead of storing vectors of samples, we could store a single buffer.
Expected performance impact:
- Lower memory overhead in child processes
- Fewer dropped IPC messages (due to lower size)
- No change to runtime costs (IPC already uses bulk APIs on the main process so there ought not to be a change to the number of tasks on the dispatcher or lock contention. Each sample still needs to perform its calculations to become appropriately bucketed)
- Mayyyybe slightly better main process performance since bucketing calculations per sample will be done on the instrumenting thread of the instrumenting process, instead of in the main process (though that's just small math)
- Similarly: Mayyyyybe slightly worse child process performance, esp. on the instrumenting thread (no dispatcher on child processes)
Because I initially wasn't 100% sure what chutten was proposing:
The idea would be to use the start_buffer API to record into a memory-only histogram, that we can then serialize in the child process and apply again in the parent process.
As is, this won't work:
start_bufferties the histogram to the metric its used on (so you can't accidentally apply it to the wrong metric)- but we don't have any metric in the child process to tie it to
- the histogram is currently not serializable
Those things could be addressed. We would need to provide a low-level API that allows us to construct that histogram, make it serializable and also reapply it later.
Some experimentation if that really helps should be done before we commit to this approach.
Updated•11 months ago
|
Description
•