test(profiling): add profiles dictionary benchmarks by taegyunkim · Pull Request #2088 · DataDog/libdatadog

taegyunkim · 2026-06-05T14:05:50Z

What does this PR do?

Adds a focused Criterion benchmark for ProfilesDictionary unique string insertion.

The benchmark uses ProfilesDictionary and covers 1, 2, 4, and 16 producer threads, so follow-up arena sizing/growth changes have a baseline in the GitLab benchmark job.

Why these thread counts?

This benchmark is focused on dictionary string interning. It is not a full end-to-end profiler benchmark.

Thread count	Why it is useful
1	Approximates single-writer consumers such as ddprof. ddprof appears to intern from the worker thread while export happens from a separate inactive profile buffer.
2	Approximates current dd-trace-py contention: one native stack sampler thread can intern off-GIL while one Python/Cython collector path is active under the GIL.
4 / 16	Stress cases for future higher-concurrency scenarios, including possible free-threaded/no-GIL Python work.

In dd-trace-py, profile mutation and serialization are guarded by profile_mtx, but dictionary interning can happen before a sample is added to the profile. This means dictionary insertion can still be concurrent even when profile writes are serialized.

What this does not cover

This benchmark does not model every profiler behavior. In particular, it does not cover:

function or mapping insertion,
duplicate-heavy/cached lookup workloads,
profile serialization reading from the dictionary,
full profiler end-to-end behavior.

Why only `ProfilesDictionary`?

I originally tried an additional synthetic benchmark comparing 4 vs 16 shards. Local exploratory results suggested 16 shards helps once there is concurrent insertion:

1 thread:   4 shards ~40 µs,   16 shards ~55 µs
2 threads:  4 shards ~157 µs,  16 shards ~129 µs
4 threads:  4 shards ~385 µs,  16 shards ~280 µs
16 threads: 4 shards ~2.64 ms, 16 shards ~1.61 ms

However, that synthetic comparison also changed total initial hash-table capacity because the capacity was applied per shard. Since the current follow-up keeps the production shard count at 16, this PR stays minimal and only adds the ProfilesDictionary benchmark.

If we revisit shard count later, we should add a dedicated shard-count benchmark that holds total starting capacity constant across shard counts.

How to test the change?

cargo +nightly-2026-02-08 fmt --all -- --check
cargo check -p libdd-profiling --benches
cargo +stable clippy -p libdd-profiling --benches -- -D warnings

PROF-14423

github-actions · 2026-06-05T14:08:06Z

📚 Documentation Check Results

⚠️ 649 documentation warning(s) found

📦 `libdd-profiling` - 649 warning(s)

Updated: 2026-06-09 21:17:20 UTC | Commit: 3b0a92f | missing-docs job results

github-actions · 2026-06-05T14:08:23Z

Clippy Allow Annotation Report

Comparing clippy allow annotations between branches:

Base Branch: origin/main
PR Branch: origin/taegyunkim/prof-14423-prof-dictinary-bench

Summary by Rule

Rule	Base Branch	PR Branch	Change

Annotation Counts by File

File	Base Branch	PR Branch	Change

Annotation Stats by Crate

Crate	Base Branch	PR Branch	Change
`clippy-annotation-reporter`	5	5	No change (0%)
`datadog-ffe-ffi`	1	1	No change (0%)
`datadog-ipc`	21	21	No change (0%)
`datadog-live-debugger`	4	4	No change (0%)
`datadog-live-debugger-ffi`	10	10	No change (0%)
`datadog-profiling-replayer`	4	4	No change (0%)
`datadog-sidecar`	46	46	No change (0%)
`libdd-common`	13	13	No change (0%)
`libdd-common-ffi`	12	12	No change (0%)
`libdd-data-pipeline`	5	5	No change (0%)
`libdd-ddsketch`	2	2	No change (0%)
`libdd-dogstatsd-client`	1	1	No change (0%)
`libdd-profiling`	13	13	No change (0%)
`libdd-remote-config`	4	4	No change (0%)
`libdd-telemetry`	20	20	No change (0%)
`libdd-tinybytes`	4	4	No change (0%)
`libdd-trace-normalization`	2	2	No change (0%)
`libdd-trace-obfuscation`	3	3	No change (0%)
`libdd-trace-stats`	1	1	No change (0%)
`libdd-trace-utils`	11	11	No change (0%)
Total	182	182	No change (0%)

About This Report

This report tracks Clippy allow annotations for specific rules, showing how they've changed in this PR. Decreasing the number of these annotations generally improves code quality.

github-actions · 2026-06-05T14:09:44Z

🔒 Cargo Deny Results

⚠️ 6 issue(s) found, showing only errors (advisories, bans, sources)

📦 `libdd-profiling` - 6 error(s)

Show output

error[vulnerability]: NSEC3 closest-encloser proof validation enters unbounded loop on cross-zone responses
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:79:1
   │
79 │ hickory-proto 0.25.2 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0118
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0118
   ├ The NSEC3 closest-encloser proof validation in `hickory-proto`'s
     `DnssecDnsHandle` walks from the QNAME up to the SOA owner name, building a
     list of candidate encloser names. The iterator used assumes the
     QNAME is a descendant of the SOA owner, terminating only when the current
     candidate equals the SOA name. When the SOA in a response's authority section
     is not an ancestor of the QNAME, the loop stalls at the DNS root and never
     terminates, repeatedly calling `Name::base_name()` and pushing newly allocated
     `Name` and hashed-name entries into the candidate `Vec`.
     
     The bug is reachable by any caller of `DnssecDnsHandle` — including the
     resolver, recursor, and client — when built with the `dnssec-ring` or
     `dnssec-aws-lc-rs` feature and configured to perform DNSSEC validation. It is
     triggered while validating a NoData or NXDomain response whose authority
     section contains an SOA record from a zone other than an ancestor of the
     QNAME, on a code path that requires NSEC3 closest-encloser proof. In practice
     this can be reached through an insecure CNAME chain that crosses zone
     boundaries into a DNSSEC-signed zone returning NoData, but the minimum
     condition is just a mismatched SOA owner on a response requiring NSEC3
     validation.
     
     A `debug_assert_ne!(name, Name::root())` guards the loop body, so debug builds
     abort with a panic on the first iteration past the root. Release builds
     compile the assertion out and run the loop unbounded, allocating until the
     process exhausts available memory (OOM). A reachable upstream attacker who
     can return such a response can therefore crash a debug-built validator or
     exhaust memory on a release-built one.
     
     The affected code was migrated from `hickory-proto` to `hickory-net` as part of
     the 0.26.0 release. The `hickory-proto` 0.26.x release no longer offers
     `DnssecDnsHandle` and so we recommend all affected users update to `hickory-net`
     0.26.1 when the implementation of that type is required.
   ├ Announcement: https://github.com/hickory-dns/hickory-dns/security/advisories/GHSA-3v94-mw7p-v465
   ├ Solution: No safe upgrade is available!
   ├ hickory-proto v0.25.2
     └── hickory-resolver v0.25.2
         └── reqwest v0.13.2
             ├── libdd-common v4.2.0
             │   └── libdd-profiling v1.0.0
             │       └── (dev) libdd-profiling v1.0.0 (*)
             └── libdd-profiling v1.0.0 (*)

error[vulnerability]: CPU exhaustion during message encoding due to O(n²) name compression
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:79:1
   │
79 │ hickory-proto 0.25.2 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0119
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0119
   ├ During message encoding, `hickory-proto`'s `BinEncoder` stores pointers to
     labels that are candidates for name compression in a `Vec<(usize, Vec<u8>)>`.
     The name compression logic then searches for matches with a linear scan.
     
     A malicious message with many records can both introduce many candidate labels,
     and invoke this linear scan many times. This can amplify CPU exhaustion in DoS
     attacks.
     
     This is similar to
     [CVE-2024-8508](https://www.nlnetlabs.nl/downloads/unbound/CVE-2024-8508.txt).
     
     We recommend all affected users update to `hickory-proto` 0.26.1 for the fix.
   ├ Announcement: https://github.com/hickory-dns/hickory-dns/security/advisories/GHSA-q2qq-hmj6-3wpp
   ├ Solution: Upgrade to >=0.26.1 (try `cargo update -p hickory-proto`)
   ├ hickory-proto v0.25.2
     └── hickory-resolver v0.25.2
         └── reqwest v0.13.2
             ├── libdd-common v4.2.0
             │   └── libdd-profiling v1.0.0
             │       └── (dev) libdd-profiling v1.0.0 (*)
             └── libdd-profiling v1.0.0 (*)

error[unsound]: Rand is unsound with a custom logger using `rand::rng()`
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:157:1
    │
157 │ rand 0.8.5 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ unsound advisory detected
    │
    ├ ID: RUSTSEC-2026-0097
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0097
    ├ It has been reported (by @lopopolo) that the `rand` library is [unsound](https://rust-lang.github.io/unsafe-code-guidelines/glossary.html#soundness-of-code--of-a-library) (i.e. that safe code using the public API can cause Undefined Behaviour) when all the following conditions are met:
      
      - The `log` and `thread_rng` features are enabled
      - A [custom logger](https://docs.rs/log/latest/log/#implementing-a-logger) is defined
      - The custom logger accesses `rand::rng()` (previously `rand::thread_rng()`) and calls any `TryRng` (previously `RngCore`) methods on `ThreadRng`
      - The `ThreadRng` (attempts to) reseed while called from the custom logger (this happens every 64 kB of generated data)
      - Trace-level logging is enabled or warn-level logging is enabled and the random source (the `getrandom` crate) is unable to provide a new seed
      
      `TryRng` (previously `RngCore`) methods for `ThreadRng` use `unsafe` code to cast `*mut BlockRng<ReseedingCore>` to `&mut BlockRng<ReseedingCore>`. When all the above conditions are met this results in an aliased mutable reference, violating the Stacked Borrows rules. Miri is able to detect this violation in sample code. Since construction of [aliased mutable references is Undefined Behaviour](https://doc.rust-lang.org/stable/nomicon/references.html), the behaviour of optimized builds is hard to predict.
    ├ Announcement: https://github.com/rust-random/rand/pull/1763
    ├ Solution: Upgrade to >=0.10.1 OR <0.10.0, >=0.9.3 OR <0.9.0, >=0.8.6 (try `cargo update -p rand`)
    ├ rand v0.8.5
      ├── libdd-common v4.2.0
      │   └── libdd-profiling v1.0.0
      │       └── (dev) libdd-profiling v1.0.0 (*)
      ├── libdd-profiling v1.0.0 (*)
      └── proptest v1.5.0
          └── (dev) libdd-profiling v1.0.0 (*)

error[vulnerability]: Name constraints for URI names were incorrectly accepted
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:181:1
    │
181 │ rustls-webpki 0.103.10 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
    │
    ├ ID: RUSTSEC-2026-0098
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0098
    ├ Name constraints for URI names were ignored and therefore accepted.
      
      Note this library does not provide an API for asserting URI names, and URI name constraints are otherwise not implemented.  URI name constraints are now rejected unconditionally.
      
      Since name constraints are restrictions on otherwise properly-issued certificates, this bug is reachable only after signature verification and requires misissuance to exploit.
      
      This vulnerability is identified as [GHSA-965h-392x-2mh5](https://github.com/rustls/webpki/security/advisories/GHSA-965h-392x-2mh5). Thank you to @1seal for the report.
    ├ Solution: Upgrade to >=0.103.12, <0.104.0-alpha.1 OR >=0.104.0-alpha.6 (try `cargo update -p rustls-webpki`)
    ├ rustls-webpki v0.103.10
      ├── rustls v0.23.37
      │   ├── hyper-rustls v0.27.7
      │   │   ├── libdd-common v4.2.0
      │   │   │   └── libdd-profiling v1.0.0
      │   │   │       └── (dev) libdd-profiling v1.0.0 (*)
      │   │   └── reqwest v0.13.2
      │   │       ├── libdd-common v4.2.0 (*)
      │   │       └── libdd-profiling v1.0.0 (*)
      │   ├── libdd-common v4.2.0 (*)
      │   ├── libdd-profiling v1.0.0 (*)
      │   ├── reqwest v0.13.2 (*)
      │   ├── rustls-platform-verifier v0.6.2
      │   │   ├── libdd-profiling v1.0.0 (*)
      │   │   └── reqwest v0.13.2 (*)
      │   └── tokio-rustls v0.26.0
      │       ├── hyper-rustls v0.27.7 (*)
      │       ├── libdd-common v4.2.0 (*)
      │       └── reqwest v0.13.2 (*)
      └── rustls-platform-verifier v0.6.2 (*)

error[vulnerability]: Name constraints were accepted for certificates asserting a wildcard name
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:181:1
    │
181 │ rustls-webpki 0.103.10 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
    │
    ├ ID: RUSTSEC-2026-0099
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0099
    ├ Permitted subtree name constraints for DNS names were accepted for certificates asserting a wildcard name.
      
      This was incorrect because, given a name constraint of `accept.example.com`, `*.example.com` could feasibly allow a name of `reject.example.com` which is outside the constraint.
      This is very similar to [CVE-2025-61727](https://go.dev/issue/76442).
      
      Since name constraints are restrictions on otherwise properly-issued certificates, this bug is reachable only after signature verification and requires misissuance to exploit.
      
      This vulnerability is identified as [GHSA-xgp8-3hg3-c2mh](https://github.com/rustls/webpki/security/advisories/GHSA-xgp8-3hg3-c2mh). Thank you to @1seal for the report.
    ├ Solution: Upgrade to >=0.103.12, <0.104.0-alpha.1 OR >=0.104.0-alpha.6 (try `cargo update -p rustls-webpki`)
    ├ rustls-webpki v0.103.10
      ├── rustls v0.23.37
      │   ├── hyper-rustls v0.27.7
      │   │   ├── libdd-common v4.2.0
      │   │   │   └── libdd-profiling v1.0.0
      │   │   │       └── (dev) libdd-profiling v1.0.0 (*)
      │   │   └── reqwest v0.13.2
      │   │       ├── libdd-common v4.2.0 (*)
      │   │       └── libdd-profiling v1.0.0 (*)
      │   ├── libdd-common v4.2.0 (*)
      │   ├── libdd-profiling v1.0.0 (*)
      │   ├── reqwest v0.13.2 (*)
      │   ├── rustls-platform-verifier v0.6.2
      │   │   ├── libdd-profiling v1.0.0 (*)
      │   │   └── reqwest v0.13.2 (*)
      │   └── tokio-rustls v0.26.0
      │       ├── hyper-rustls v0.27.7 (*)
      │       ├── libdd-common v4.2.0 (*)
      │       └── reqwest v0.13.2 (*)
      └── rustls-platform-verifier v0.6.2 (*)

error[vulnerability]: Reachable panic in certificate revocation list parsing
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:181:1
    │
181 │ rustls-webpki 0.103.10 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
    │
    ├ ID: RUSTSEC-2026-0104
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0104
    ├ A panic was reachable when parsing certificate revocation lists via [`BorrowedCertRevocationList::from_der`]
      or [`OwnedCertRevocationList::from_der`].  This was the result of mishandling a syntactically valid empty
      `BIT STRING` appearing in the `onlySomeReasons` element of a `IssuingDistributionPoint` CRL extension.
      
      This panic is reachable prior to a CRL's signature being verified.
      
      Applications that do not use CRLs are not affected.
      
      Thank you to @tynus3 for the report.
    ├ Solution: Upgrade to >=0.103.13, <0.104.0-alpha.1 OR >=0.104.0-alpha.7 (try `cargo update -p rustls-webpki`)
    ├ rustls-webpki v0.103.10
      ├── rustls v0.23.37
      │   ├── hyper-rustls v0.27.7
      │   │   ├── libdd-common v4.2.0
      │   │   │   └── libdd-profiling v1.0.0
      │   │   │       └── (dev) libdd-profiling v1.0.0 (*)
      │   │   └── reqwest v0.13.2
      │   │       ├── libdd-common v4.2.0 (*)
      │   │       └── libdd-profiling v1.0.0 (*)
      │   ├── libdd-common v4.2.0 (*)
      │   ├── libdd-profiling v1.0.0 (*)
      │   ├── reqwest v0.13.2 (*)
      │   ├── rustls-platform-verifier v0.6.2
      │   │   ├── libdd-profiling v1.0.0 (*)
      │   │   └── reqwest v0.13.2 (*)
      │   └── tokio-rustls v0.26.0
      │       ├── hyper-rustls v0.27.7 (*)
      │       ├── libdd-common v4.2.0 (*)
      │       └── reqwest v0.13.2 (*)
      └── rustls-platform-verifier v0.6.2 (*)

advisories FAILED, bans ok, sources ok

Updated: 2026-06-09 21:17:24 UTC | Commit: 3b0a92f | dependency-check job results

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 427e0ea0f9

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

codecov-commenter · 2026-06-05T14:19:46Z

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 73.53%. Comparing base (98016ad) to head (477834f).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2088      +/-   ##
==========================================
- Coverage   73.54%   73.53%   -0.02%     
==========================================
  Files         475      475              
  Lines       79007    79007              
==========================================
- Hits        58109    58095      -14     
- Misses      20898    20912      +14

Components	Coverage Δ
libdd-crashtracker	`65.32% <ø> (-0.02%)`	⬇️
libdd-crashtracker-ffi	`37.68% <ø> (ø)`
libdd-agent-client	`83.79% <ø> (ø)`
libdd-alloc	`98.77% <ø> (ø)`
libdd-data-pipeline	`86.27% <ø> (+0.01%)`	⬆️
libdd-data-pipeline-ffi	`73.86% <ø> (ø)`
libdd-common	`79.93% <ø> (ø)`
libdd-common-ffi	`74.41% <ø> (ø)`
libdd-telemetry	`73.34% <ø> (ø)`
libdd-telemetry-ffi	`31.36% <ø> (ø)`
libdd-dogstatsd-client	`82.64% <ø> (ø)`
datadog-ipc	`76.36% <ø> (ø)`
libdd-profiling	`81.68% <ø> (-0.03%)`	⬇️
libdd-profiling-ffi	`64.79% <ø> (ø)`
libdd-sampling	`97.48% <ø> (ø)`
datadog-sidecar	`36.51% <ø> (+0.02%)`	⬆️
datdog-sidecar-ffi	`12.23% <ø> (ø)`
spawn-worker	`48.86% <ø> (ø)`
libdd-tinybytes	`93.80% <ø> (ø)`
libdd-trace-normalization	`81.71% <ø> (ø)`
libdd-trace-obfuscation	`87.30% <ø> (ø)`
libdd-trace-protobuf	`68.25% <ø> (ø)`
libdd-trace-utils	`89.32% <ø> (ø)`
libdd-tracer-flare	`86.57% <ø> (ø)`
libdd-log	`74.83% <ø> (ø)`

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

datadog-datadog-prod-us1-2 · 2026-06-05T14:19:53Z

Tests

🎉 All green!

🧪 All tests passed
❄️ No new flaky tests detected

🎯 Code Coverage (details)
• Patch Coverage: 100.00%
• Overall Coverage: 73.52% (-0.01%)

_{This comment will be updated automatically if new data arrives.

🔗 Commit SHA: 5c54a65 | Docs | Datadog PR Page | Give us feedback!}

dd-octo-sts · 2026-06-05T14:42:02Z

Artifact Size Benchmark Report

aarch64-alpine-linux-musl

Artifact	Baseline	Commit	Change
/aarch64-alpine-linux-musl/lib/libdatadog_profiling.so	7.70 MB	7.70 MB	0% (0 B) 👌
/aarch64-alpine-linux-musl/lib/libdatadog_profiling.a	83.68 MB	83.68 MB	0% (0 B) 👌

aarch64-unknown-linux-gnu

Artifact	Baseline	Commit	Change
/aarch64-unknown-linux-gnu/lib/libdatadog_profiling.a	94.78 MB	94.78 MB	0% (0 B) 👌
/aarch64-unknown-linux-gnu/lib/libdatadog_profiling.so	10.34 MB	10.34 MB	0% (0 B) 👌

libdatadog-x64-windows

Artifact	Baseline	Commit	Change
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.dll	24.83 MB	24.83 MB	0% (0 B) 👌
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.lib	86.89 KB	86.89 KB	0% (0 B) 👌
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.pdb	180.82 MB	180.84 MB	+.01% (+24.00 KB) 🔍
/libdatadog-x64-windows/debug/static/datadog_profiling_ffi.lib	925.68 MB	925.68 MB	0% (0 B) 👌
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.dll	8.09 MB	8.09 MB	0% (0 B) 👌
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.lib	86.89 KB	86.89 KB	0% (0 B) 👌
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.pdb	23.93 MB	23.93 MB	0% (0 B) 👌
/libdatadog-x64-windows/release/static/datadog_profiling_ffi.lib	47.78 MB	47.78 MB	0% (0 B) 👌

libdatadog-x86-windows

Artifact	Baseline	Commit	Change
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.dll	21.52 MB	21.52 MB	0% (0 B) 👌
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.lib	88.26 KB	88.26 KB	0% (0 B) 👌
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.pdb	184.89 MB	184.90 MB	+0% (+8.00 KB) 👌
/libdatadog-x86-windows/debug/static/datadog_profiling_ffi.lib	918.35 MB	918.35 MB	0% (0 B) 👌
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.dll	6.24 MB	6.24 MB	0% (0 B) 👌
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.lib	88.26 KB	88.26 KB	0% (0 B) 👌
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.pdb	25.66 MB	25.66 MB	0% (0 B) 👌
/libdatadog-x86-windows/release/static/datadog_profiling_ffi.lib	45.41 MB	45.41 MB	0% (0 B) 👌

x86_64-alpine-linux-musl

Artifact	Baseline	Commit	Change
/x86_64-alpine-linux-musl/lib/libdatadog_profiling.a	74.60 MB	74.60 MB	0% (0 B) 👌
/x86_64-alpine-linux-musl/lib/libdatadog_profiling.so	8.58 MB	8.58 MB	0% (0 B) 👌

x86_64-unknown-linux-gnu

Artifact	Baseline	Commit	Change
/x86_64-unknown-linux-gnu/lib/libdatadog_profiling.a	90.02 MB	90.02 MB	0% (0 B) 👌
/x86_64-unknown-linux-gnu/lib/libdatadog_profiling.so	10.44 MB	10.44 MB	0% (0 B) 👌

morrisonlevi

How stable is the benchmark in your experience so far? It seems like it would be pretty variable, but at least you have a startup barrier in there.

taegyunkim requested a review from a team as a code owner June 5, 2026 14:05

taegyunkim added the profiling Relates to the profiling* modules. label Jun 5, 2026

chatgpt-codex-connector Bot reviewed Jun 5, 2026

View reviewed changes

Comment thread libdd-profiling/benches/profiles_dictionary.rs Outdated

github-actions Bot removed the profiling Relates to the profiling* modules. label Jun 5, 2026

test(profiling): add profiles dictionary benchmarks

477834f

taegyunkim force-pushed the taegyunkim/prof-14423-prof-dictinary-bench branch from 2e23e15 to 477834f Compare June 5, 2026 20:26

taegyunkim mentioned this pull request Jun 5, 2026

perf(profiling): reduce profiler arena memory footprint #2048

Draft

morrisonlevi reviewed Jun 8, 2026

View reviewed changes

Comment thread libdd-profiling/benches/profiles_dictionary.rs Outdated

Comment thread libdd-profiling/benches/profiles_dictionary.rs Outdated

danielsn reviewed Jun 9, 2026

View reviewed changes

taegyunkim added 6 commits June 9, 2026 16:32

Define consts and update comments

79a6152

drop inner black_box

90514f9

add comments

8121b66

impl varying length strings

b123964

add comment why the function partitions the strins

e4a91af

Merge branch 'main' into taegyunkim/prof-14423-prof-dictinary-bench

5c54a65

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

test(profiling): add profiles dictionary benchmarks#2088

test(profiling): add profiles dictionary benchmarks#2088
taegyunkim wants to merge 7 commits into
mainfrom
taegyunkim/prof-14423-prof-dictinary-bench

taegyunkim commented Jun 5, 2026 •

edited by atlassian Bot

Loading

Uh oh!

github-actions Bot commented Jun 5, 2026 •

edited

Loading

Uh oh!

github-actions Bot commented Jun 5, 2026 •

edited

Loading

Uh oh!

github-actions Bot commented Jun 5, 2026 •

edited

Loading

Uh oh!

chatgpt-codex-connector Bot left a comment

Uh oh!

Uh oh!

codecov-commenter commented Jun 5, 2026 •

edited

Loading

Uh oh!

datadog-datadog-prod-us1-2 Bot commented Jun 5, 2026 •

edited by datadog-prod-us1-3 Bot

Loading

Uh oh!

dd-octo-sts Bot commented Jun 5, 2026 •

edited

Loading

Uh oh!

morrisonlevi left a comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Conversation

taegyunkim commented Jun 5, 2026 • edited by atlassian Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What does this PR do?

Why these thread counts?

What this does not cover

Why only ProfilesDictionary?

How to test the change?

Uh oh!

github-actions Bot commented Jun 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

📚 Documentation Check Results

📦 libdd-profiling - 649 warning(s)

Uh oh!

github-actions Bot commented Jun 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Clippy Allow Annotation Report

Summary by Rule

Annotation Counts by File

Annotation Stats by Crate

About This Report

Uh oh!

github-actions Bot commented Jun 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

🔒 Cargo Deny Results

📦 libdd-profiling - 6 error(s)

Uh oh!

chatgpt-codex-connector Bot left a comment

Choose a reason for hiding this comment

💡 Codex Review

Uh oh!

Uh oh!

codecov-commenter commented Jun 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

datadog-datadog-prod-us1-2 Bot commented Jun 5, 2026 • edited by datadog-prod-us1-3 Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dd-octo-sts Bot commented Jun 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Artifact Size Benchmark Report

Uh oh!

morrisonlevi left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

taegyunkim commented Jun 5, 2026 •

edited by atlassian Bot

Loading

Why only `ProfilesDictionary`?

github-actions Bot commented Jun 5, 2026 •

edited

Loading

📦 `libdd-profiling` - 649 warning(s)

github-actions Bot commented Jun 5, 2026 •

edited

Loading

github-actions Bot commented Jun 5, 2026 •

edited

Loading

📦 `libdd-profiling` - 6 error(s)

codecov-commenter commented Jun 5, 2026 •

edited

Loading

datadog-datadog-prod-us1-2 Bot commented Jun 5, 2026 •

edited by datadog-prod-us1-3 Bot

Loading

dd-octo-sts Bot commented Jun 5, 2026 •

edited

Loading