subscriber: make Registry::enter/exit much faster (backport #1058) #1059
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This backports #1058 to v0.1.x. This was already approved on master.
Motivation
We've tried very hard to make sure that entering and exiting spans is
lightweight...in the
tracing-core
core machinery. Unfortunately, wehaven't done any benchmarking of how subscriber implementations actually
handle enter/exit events. It turns out that in
tracing-subscriber
'sRegistry
, there's actually significant overhead for entering a span:calling
span.enter()
may take as long as 69 ns (on my machine).Solution
I've written some microbenchmarks for entering and exiting enabled spans
using
tracing-subscriber::fmt
, comparing them with the overhead ofcalling
enter
on an enabled span. Based on this, I've made someperformance improvements. These optimizations include:
HashSet
that's used for tracking previously enteredspan IDs, in favor of linear search. Span stacks probably never deep
enough for a hashmap to be faster than iterating over a couple of
vec indices.
elements. This means we'll never have a lag spike from reallocating,
as I think it'll almost never be deeper than 64 IDs.
This makes entering and exiting enabled spans significantly faster:

It would be nice to continue optimizing this, but this might be about
the best it gets given the other requirements that we're now making
assertions about.
Signed-off-by: Eliza Weisman [email protected]
Motivation
Solution