Ideally we'd like event recording to not even take the sharded read lock on the fast path. This should be possible by keeping the TLS in some kind of atomic linked list instead of as a map inside the critical state. There are two main challenges with this approach:
How do we deal with span::Id re-use and invalidation? If the writers kept a cache of the state for spans in their TLS, they wouldn't know when that state is out-of-date if a span::Id is dropped and then re-created rapidly. We could conceivably switch away from Slab and just use a monotonically increasing u64 as the span::Id instead, though it would slow down lookups as they'd now need to navigate a map of some kind.
It precludes one thread (most likely the one that'll read the histograms) from dropping all the recorders to force synchronization of the histograms. Maybe we're okay forgoing that feature?
Ideally we'd like event recording to not even take the sharded read lock on the fast path. This should be possible by keeping the TLS in some kind of atomic linked list instead of as a map inside the critical state. There are two main challenges with this approach:
span::Idre-use and invalidation? If the writers kept a cache of the state for spans in their TLS, they wouldn't know when that state is out-of-date if aspan::Idis dropped and then re-created rapidly. We could conceivably switch away fromSlaband just use a monotonically increasingu64as thespan::Idinstead, though it would slow down lookups as they'd now need to navigate a map of some kind.