Investigate using the "tracing" crate for Gecko profiler markers from Rust code
Categories
(Core :: Gecko Profiler, task, P2)
Tracking
()
People
(Reporter: mstange, Assigned: aabh)
References
(Blocks 1 open bug)
Details
(Whiteboard: [fxp])
Attachments
(1 obsolete file)
At the moment, we have a few pieces of Rust code that emit Gecko Profiler markers by exposing their own marker creation function via FFI. We should try to simplify that process.
In the Rust ecosystem, the tracing crate is a popular mechanism to emit generic marker-like data: tracing has "spans" and "events", and it has a generic subscriber interface that allows arbitrary other code to listen to those spans and events.
I think it might work well to have the Gecko Profiler install itself as a tracing subscriber, and convert spans and events to Gecko Profiler markers. Then instrumenting our Rust code with profiler markers becomes as easy as adding #[tracing::instrument] attributes to the relevant functions.
Skimming the crate docs, simple one-string marker look easy. And if we want to include the trace level, we could have a payload just for Rust markers.
For those with arbitrary fields, either we'd need to fold them into one string on the spot (most expensive), or wait for bug 1640956 to allow more flexible marker payloads. (Or one then the other when possible.)
Or... could we teach Rust how to serialize directly into the profiler buffer the same way C++ does?
:kvark told me that they switched from tracing crate to profiling crate in wgpu and they seem very satisfied with it. They are also thinking about switching that in WebRender. We can also think about using this crate.
| Assignee | ||
Updated•1 year ago
|
| Assignee | ||
Updated•1 year ago
|
| Assignee | ||
Comment 3•1 year ago
|
||
Updated•1 year ago
|
Updated•1 year ago
|
Updated•9 months ago
|
Description
•