profiling: Add abstraction over tracing-rs #40160
Conversation
|
CC @delan who I think had some ideas for moving away from tracing for profiling, though I could be misremembering. |
| #[cfg(feature = "tracing")] | ||
| #[allow(dead_code)] | ||
| span: tracing::span::EnteredSpan, | ||
| span: profile_traits::servo_tracing::span::EnteredSpan, |
There was a problem hiding this comment.
I guess this is the part that is actually interesting. We could avoid the feature flag here, by exposing the Span type and friends in profile_traits. The actual implementation of the types could depend on additional feature flags (e.g. tracing-rs enables the tracing-rs backend, hitrace enables the hitrace backend, nothing enables the dummy backend as a fallback. Multiple feature enabled would result in a compile time error, or we decide on a priority)
There was a problem hiding this comment.
I removed this part again, and leave handling this use-case to a follow-up
Signed-off-by: Jonathan Schwender <schwenderjonathan@gmail.com>
Signed-off-by: Jonathan Schwender <schwenderjonathan@gmail.com>
2555db2 to
2d6af3b
Compare
|
Rebased the changes from last time. Probably best to land this as-is, and iterate over the remaining tracing usages in a follow-up. |
There are multiple motivating factors for this change:
tracing-rscan and is commonly used for structured logging, to gain understanding in what is happening in concurrent code. We would like to attempt to make a distinction of the performance tracing related usage and the logging related usage.Testing: Tested manually by building with and without the
tracingfeature. In CI we also build with the tracing feature in the HarmonyOS build. We don't have any automated tests for the correctness / presence of the traced entries.