Skip to content

benchmark: add micro-benchmarks for TraceID hex formatting and parsing#311

Merged
xlamorlette-datadog merged 2 commits into
DataDog:mainfrom
AneesPatel:bench/trace-id-hex-utilities
May 26, 2026
Merged

benchmark: add micro-benchmarks for TraceID hex formatting and parsing#311
xlamorlette-datadog merged 2 commits into
DataDog:mainfrom
AneesPatel:bench/trace-id-hex-utilities

Conversation

@AneesPatel
Copy link
Copy Markdown
Contributor

Description

Adds benchmark/trace_id_bench.cpp to introduce targeted Google Benchmark coverage for the 128-bit and 64-bit TraceID formatting paths. Also updates benchmark/CMakeLists.txt to include the new benchmark executable.

Baseline Metrics (Ubuntu 22.04 / GCC 11.4):

Benchmark Time (ns/op) Iterations Notes
BM_TraceID_HexPadded 204 ns 3.6M Full 128-bit ID to 32-char hex. Cost reflects two underlying std::string allocations and concatenation.
BM_TraceID_ParseHex_128bit 108 ns 6.5M W3C traceparent extraction path.
BM_TraceID_ParseHex_64bit 60 ns 11.8M Legacy 64-bit extraction path.
BM_HexPadded_uint64 46 ns 17.6M Single to_chars + std::string alloc.
BM_Hex_uint64 24 ns 29.5M No padding.

Motivation

TraceID::hex_padded() is called on every outgoing W3C traceparent header injection, and TraceID::parse_hex() on every incoming extraction. Because these functions sit in the hottest path of distributed tracing, their latency and allocation overhead multiply across millions of spans.

Currently, the underlying hex_padded<uint64_t>() and hex<uint64_t>() functions utilize a stack-buffer-to-std::string pattern. While the existing BM_TraceTinyCCSource benchmark provides excellent end-to-end throughput data, it cannot isolate micro-regressions in these specific serialization operations.

This baseline provides the data needed to safely prevent future regressions and evaluate allocation-reduction strategies in the critical path.

Jira ticket

N/A

Additional Notes

  • Validated locally via Linux (WSL2 Ubuntu 22.04) with GCC 11.4.

How to run

mkdir .build && cd .build
cmake .. -DDD_TRACE_BUILD_BENCHMARK=1 -DCMAKE_BUILD_TYPE=Release
make -j
./benchmark/dd_trace_cpp-benchmark --benchmark_filter='^BM_TraceID|^BM_Hex'

@AneesPatel AneesPatel requested review from a team as code owners April 23, 2026 03:31
@AneesPatel AneesPatel requested review from tabgok and removed request for a team April 23, 2026 03:31
@tabgok tabgok requested review from xlamorlette-datadog and removed request for tabgok April 30, 2026 18:58
Copy link
Copy Markdown
Collaborator

@xlamorlette-datadog xlamorlette-datadog left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please, what is you personal objective in submitting this PR?

Comment thread benchmark/trace_id_bench.cpp Outdated
Comment thread benchmark/trace_id_bench.cpp Outdated
@AneesPatel AneesPatel force-pushed the bench/trace-id-hex-utilities branch from 168c7b0 to 455299d Compare May 21, 2026 21:14
@AneesPatel
Copy link
Copy Markdown
Contributor Author

Hi @xlamorlette-datadog, thanks for the review and the great catch on the padding paths!

To answer your question, I'm currently an undergraduate studying computer science with an interest in low-latency systems and performance-oriented C++. My goal with this PR is to add measurable coverage for these serialization paths so that future allocation-reduction work (e.g., using std::to_chars with stack-allocated buffers to avoid the std::string heap allocation) can be evaluated with concrete latency data instead of guesswork.

I completely agree with testing the edge cases, and I've just pushed a commit that factorizes the tests using BENCHMARK_CAPTURE exactly as you suggested.

One interesting finding from my local runs is that BM_TraceID_HexPadded/WithPadding ({1, 0}) actually ran faster than the NoPadding case (~88 ns vs ~131 ns on my machine). It looks like when high == 0 the implementation skips formatting the high half entirely, which is why the WithPadding case ends up faster despite the name.

Let me know if the new structure looks good, thanks again for the review.

@datadog-prod-us1-3
Copy link
Copy Markdown

datadog-prod-us1-3 Bot commented May 22, 2026

Pipelines

Fix all issues with BitsAI

⚠️ Warnings

🚦 13 Pipeline jobs failed

Development | build-linux-cmake (gnu, arm64)   View in Datadog   GitHub Actions

🛟 This job is unlikely to succeed on retry. Please review your pipeline configuration. Internal Error: API key is missing

Development | build-linux-cmake (gnu, x64)   View in Datadog   GitHub Actions

🛟 This job is unlikely to succeed on retry. Please review your pipeline configuration. API key is missing for datadog-ci upload.

Development | build-linux-cmake (llvm, arm64)   View in Datadog   GitHub Actions

🛟 This job is unlikely to succeed on retry. Please review your pipeline configuration. API key is missing during execution.

View all 13 failed jobs.

Useful? React with 👍 / 👎

This comment will be updated automatically if new data arrives.
🔗 Commit SHA: 3e8fece | Docs | Datadog PR Page | Give us feedback!

@xlamorlette-datadog
Copy link
Copy Markdown
Collaborator

Some CI jobs are failing because this comes from a fork. I'm going to mirror this PR in our main repository.

@xlamorlette-datadog
Copy link
Copy Markdown
Collaborator

All CI jobs are green on the mirrored (draft) PR.

@xlamorlette-datadog
Copy link
Copy Markdown
Collaborator

xlamorlette-datadog commented May 22, 2026

@AneesPatel Would you please be able to sign your commits?
(This is blocking the PR merge.)

@AneesPatel AneesPatel force-pushed the bench/trace-id-hex-utilities branch from 455299d to 3e8fece Compare May 22, 2026 16:24
@xlamorlette-datadog xlamorlette-datadog merged commit 8563501 into DataDog:main May 26, 2026
84 of 99 checks passed
@xlamorlette-datadog
Copy link
Copy Markdown
Collaborator

@AneesPatel Thanks for your contribution!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants