fix(ddtrace/tracer): fix BenchmarkSpanStartConcurrent#4539
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files🚀 New features to boost your workflow:
|
|
✅ Tests 🎉 All green!❄️ No new flaky tests detected 🎯 Code Coverage (details) 🔗 Commit SHA: 6380cfd | Docs | Datadog PR Page | Was this helpful? React with 👍/👎 or give us feedback! |
BenchmarksBenchmark execution time: 2026-03-13 18:46:15 Comparing candidate commit 6380cfd in PR branch Found 0 performance improvements and 0 performance regressions! Performance is the same for 157 metrics, 7 unstable metrics.
|
This benchmark currently fails: --- FAIL: BenchmarkStartSpanConcurrent benchmark.go:417: B.Loop called with timer stopped benchmark.go:417: B.Loop called with timer stopped benchmark.go:417: B.Loop called with timer stopped The B.Loop docs don't seem to explicitly prohibit calling B.Loop from multiple goroutines in the same test. But in practice this is what happens since B.Loop manages the test timer internally. This benchmark can be simplified with B.RunParallel, which is specifically made for the kind of thing this benchmark is supposed to be measuring. And as a bonus the benchmark works again. We lose the synchronization prior to starting the main loop with this refactor. We could get it back if we know ahead of time how many goroutines the test is going to create. But it doesn't seem like a big loss.
4e48ab6 to
6380cfd
Compare
What does this PR do?
Refactors BenchmarkStartSpanConcurrent to use RunParallel
Motivation
This benchmark currently fails:
The B.Loop docs don't seem to explicitly prohibit calling B.Loop from
multiple goroutines in the same test. But in practice this is what
happens since B.Loop manages the test timer internally. This benchmark
can be simplified with B.RunParallel, which is specifically made for the
kind of thing this benchmark is supposed to be measuring. And as a bonus
the benchmark works again. We lose the synchronization prior to starting
the main loop with this refactor. We could get it back if we know ahead
of time how many goroutines the test is going to create. But it doesn't
seem like a big loss.