What Does This Do

Two amendments to the perf-review skill (SKILL.md and references/checks.md):

1. Pre-existing code is in scope when the diff changes its execution context. Unchanged lines stay out of scope unless the diff changes what they cost: they now run more often (onto a hotter path, or per-trace to per-span), under a lock they weren't under, on a different thread (background to application thread), or ahead of a new branch or early return that makes them run more often. Such code is flagged as carried in by this change, under the normal confidence and severity rules.
2. Propagation and header paths are exceptionally hot: findings there move up one severity notch (SEV-3 → SEV-2). This includes the propagation state behind the headers, updated on every trace whether or not a header is written: propagation tags at span start, trace-id formatting, the sampling decision's bookkeeping. Eager work for an optional propagation format (W3C/OTel tracestate, hex ids, string building, extra locks) belongs at inject/export time.

Motivation

Both come from reviewing #12397 (OTel consistent tracestate sampling, shipped in v1.67.0):

• A blind perf-review of Support OpenTelemetry consistent tracestate sampling #12397 (diff only, no extra context) caught its two structural problems: an eager OtelTraceState per trace, and a new Object() lock on every span's PTags. It missed TagValue.from("-" + samplingMechanism), a per-trace string concatenation that check First PR - Implements the Opentracing API #2 covers. The line predates the PR, but the PR moved it inside its new synchronized block on the sampling path. A context-assisted run did flag it. Rule 1 closes that gap without opening the review up to every pre-existing issue near a diff.
• Profiling put the sampling decision at ~38 ns per trace (~10% of a bare span on Zulu 17 / M1 Max), much of it propagation bookkeeping (APMLP-2048). Header and propagation handling is among the hottest code in the system. The blind run rated the eager OtelTraceState SEV-3, while the context-assisted run rated it SEV-2. Rule 2 encodes that weighting.

Additional Notes

• Open question for reviewers: is a flat one-notch bump the right weighting for header and propagation paths, or should it be narrower (e.g. only for per-trace eager work)?
• Documentation-only change to the skill. Next step: rerun the blind review on Support OpenTelemetry consistent tracestate sampling #12397 with these rules, and check that it now flags the carried-in concatenation without adding noise.

🤖 Generated with Claude Code