[processor/dynamic_sampling] move buffered spans at decision time instead of copying - #50044
Merged
songy23 merged 1 commit intoAug 4, 2026
Conversation
…tead of copying Assisted-by: Claude Fable 5
10 tasks
Pull request dashboard statusMerged · refreshed 2026-08-04 19:31 UTC Status above doesn't look right?
|
jmacd
approved these changes
Aug 4, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Description
Companion to #50026, applied to the decision path.
assembleTracedeep-copied every buffered ResourceSpans into the output at decision time, and profiling showed that copy was ~52% of decision-path allocation bytes. The buffered spans are processor-owned (created fresh inConsumeTraces) and the pending trace is discarded after the decision, so they can be moved instead.readIncomingSamplingreads the same spans and already runs before assembly; a comment now pins that ordering andfinishDecisionnils the consumed slice.Also fixes two benchmark issues found while measuring:
rvof 16 hex digits (the spec requires exactly 14), so it exercised the parse-failure path and understated real tracestate cost.BenchmarkDecidereused one pendingTrace across iterations, which breaks once spans are consumed; it now rebuilds the trace per iteration (untimed).Benchmarks (Apple M4 Pro, mean of 5 runs, measured after the benchmark fixes so before/after are like-for-like):
Link to tracking issue
Refs #49311
Testing
BenchmarkDecidecases (numbers above).Documentation
Comments on
assembleTraceandfinishDecisiondocumenting the move semantics and ordering constraint. Changelog entry included.Authorship