-
Notifications
You must be signed in to change notification settings - Fork 434
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Performance: Context holds SynchronizedSpan directly, not via HashMap #1268
Performance: Context holds SynchronizedSpan directly, not via HashMap #1268
Conversation
Looks good, always nice to be able to do perf improvements without breaking api changes too 👍 what numbers are you seeing for the diff? |
TraceContext, Baggage, and some to fix this, would be common use-case for context. If we can make these 3 top-level fields instead of putting in map/dictionary, that'd be awesome. |
From 70% to 170% speedup in checking context for active span, or is sampled or is recording. |
Codecov ReportPatch coverage is
📢 Thoughts on this report? Let us know!. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note, this would be a bit easier to review if you squashed the changes for the span
field into a single commit and had a separate commit that takes care of the Span
imports.
What's the rationale for moving from per-module to per-crate imports? Is that converging on a common style or diverging from it?
I thought I was moving to the common style, as its what's offered by auto-complete/rust-analyzer when adding new imports. I can revert if I didn't understand the current style tho... |
f6b3031
to
e381565
Compare
@djc, should be easier to review now. (Sorry, I thought I had squashed my two commits previously, but didn't.) |
- lookup on TypeId and downcasting isn't necesary - Context::with_value and current_with_value are more efficient as they no longer clone and overwrite the entry in the map which represens the current span
e381565
to
6e4ae4c
Compare
Changes
Add the
span
field below:so that current span manipulation doesn't have to traverse the expensive HashMap and then get dispatched with virtual function calls.
Further, this keeps the HashMap empty for the common case of just having a span in context and no other types (like baggage).
I get that the opentelemetry specification is trying to be general with its view that
Context
is extensible and can hold anything, but there comes a real performance penalty for handling everything through that abstraction.Results of
cargo bench -p opentelemetry_sdk --bench context
:Results of
taskset -c 2,4 cargo bench -p opentelemetry-contrib --features="api" --bench new_span
:Merge requirement checklist
CHANGELOG.md
files updated for non-trivial, user-facing changes