Skip to content

test: skip/shorten slow miri jobs - #2331

Open
morrisonlevi wants to merge 1 commit into
mainfrom
levi/slow-miri
Open

test: skip/shorten slow miri jobs#2331
morrisonlevi wants to merge 1 commit into
mainfrom
levi/slow-miri

Conversation

@morrisonlevi

@morrisonlevi morrisonlevi commented Aug 7, 2026

Copy link
Copy Markdown
Contributor

What does this PR do?

This either skips or shortens some miri jobs.

Motivation

These specific jobs were summarized as SLOW, meaning they individually took over 1 minute.

Additional Notes

Most of them exercise no direct unsafe miri code. Then one I shortened does, which is why I shortened it instead of skipping it.

How to test the change?

As usual, e.g. to run just the affected crates:

  • cargo test -p libdd-profiling -p libdd-ffe -p libdd-crashtracker -p datadog-live-debugger
  • cargo +nightly miri nextest run -p libdd-profiling -p libdd-ffe -p libdd-crashtracker -p datadog-live-debugger on Linux (portable atomic does not seem to work on macOS due to missing atomic for 128 bit types).

@morrisonlevi
morrisonlevi requested review from a team as code owners August 7, 2026 12:35
@morrisonlevi
morrisonlevi requested review from leoromanovsky and typotter and removed request for a team August 7, 2026 12:35
@datadog-datadog-us1-prod

datadog-datadog-us1-prod Bot commented Aug 7, 2026 •
edited by datadog-official Bot
Loading

Copy link
Copy Markdown

Tests

🎉 All green!

🧪 All tests passed
❄️ No new flaky tests detected

🎯 Code Coverage (details)
• Patch Coverage: 100.00%
• Overall Coverage: 75.89% (-0.02%)

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

@github-actions

github-actions Bot commented Aug 7, 2026

Copy link
Copy Markdown
Contributor

📚 Documentation Check Results

⚠️ 4077 documentation warning(s) found

📦 builder - 250 warning(s)

📦 datadog-live-debugger - 1642 warning(s)

📦 libdd-crashtracker - 1150 warning(s)

📦 libdd-ffe - 385 warning(s)

📦 libdd-profiling - 650 warning(s)

Updated: 2026-08-07 12:38:43 UTC | Commit: 9dcdb5a | missing-docs job results

@github-actions

github-actions Bot commented Aug 7, 2026

Copy link
Copy Markdown
Contributor

🔒 Cargo Deny Results

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

📦 builder - 3 error(s)

Show output 
error[vulnerability]: Quadratic run time when checking a start tag for duplicate attribute names
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:81:1
   │
81 │ quick-xml 0.37.5 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0194
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0194
   ├ `BytesStart::attributes()` returns an `Attributes` iterator which, by default
     (`with_checks(true)`), rejects a start tag that repeats an attribute name. For
     each attribute yielded, the iterator compared the new name against every name
     seen so far in the same tag using a linear scan, so a start tag with `N`
     distinct attribute names cost `O(N²)` byte comparisons. There was no bound on
     `N` other than the size of the buffered start tag.
     
     ## Impact
     
     Any code that parses untrusted XML and iterates a start tag's attributes with
     the default duplicate check enabled can be made to spend CPU time quadratic in
     the number of attributes on a single tag. Because the check is pure computation
     with no `.await`/I/O, an I/O-based timeout on the consumer (for example a read
     or request timeout) cannot interrupt it while it runs.
     
     Measured cost of a single start tag, release build:
     
     | Attributes on one tag | Time |
     |---|---|
     | 80,000  | ~6 s   |
     | 800,000 | ~10 min |
     
     The cost grows with the square of the attribute count, so a start tag of a few
     tens of megabytes can stall a parsing thread for hours. No memory is exhausted
     and the parser does not crash; the effect is CPU exhaustion on the thread doing
     the parsing: a single crafted start tag can pin a CPU core for minutes to hours,
     denying service to that worker. A deployment that places a wall-clock bound on
     parsing, or confines it to a non-critical thread, may consider the availability
     impact lower.
     
     ## Affected code paths
     
     * `BytesStart::attributes()` / `Attributes` iterated with checks enabled (the
       default), and `BytesStart::try_get_attribute`.
     * `NsReader`, which resolves namespaces by iterating a tag's attributes and so
       reaches the same check internally.
     
     Consumers that iterate attributes with `.attributes().with_checks(false)` and do
     not use `NsReader` are not affected.
     
     This was reported as reachable by a remote, unauthenticated attacker in a
     real-world RPKI relying party (NLnet Labs Routinator) via a crafted RRDP
     `snapshot.xml`.
     
     ## Remediation
     
     Upgrade to `quick-xml >= 0.41.0`, where the duplicate check keeps the linear
     scan for start tags with a small number of attributes and switches to an `O(1)`
     hash pre-filter above a threshold, making the whole tag `O(N)`. The reported
     `AttrError::Duplicated` positions are unchanged.
     
     If upgrading is not possible and duplicate-name detection is not required,
     disable it with `.attributes().with_checks(false)` (this does not help
     `NsReader` consumers, which have no equivalent opt-out before 0.41.0).
   ├ Announcement: https://github.com/tafia/quick-xml/issues/969
   ├ Solution: Upgrade to >=0.41.0 (try `cargo update -p quick-xml`)
   ├ quick-xml v0.37.5
     └── tools v40.0.0
         └── builder v40.0.0

error[vulnerability]: Unbounded namespace-declaration allocation in `NsReader` enables memory-exhaustion denial of service
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:81:1
   │
81 │ quick-xml 0.37.5 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0195
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0195
   ├ `NsReader` resolves namespaces by calling `NamespaceResolver::push` for every
     `Start`/`Empty` event *before* the event is returned to the caller. `push`
     iterated all `xmlns` / `xmlns:*` attributes on the start tag and, for each one,
     appended the prefix bytes to an internal buffer and pushed a `NamespaceBinding`
     (32 bytes on 64-bit) to an internal `Vec`, with no upper bound on the number of
     declarations.
     
     ## Impact
     
     A start tag with `N` namespace declarations drove roughly `3×` the tag's byte
     size in `NamespaceResolver` heap, allocated *inside* `quick-xml` before the
     `NsReader` consumer ever received the event and could inspect or reject it. A
     consumer that bounds its *input* size therefore still cannot bound this
     allocation: an `M`-byte start tag yields on the order of `3 × M` bytes of
     resolver heap the caller never sees.
     
     On untrusted XML this lets a remote, unauthenticated attacker force large heap
     allocations with a single start tag. With several `NsReader`s running
     concurrently on independent inputs (a common server pattern), the allocations
     stack and can exhaust process memory, causing the operating system to kill the
     process (OOM). This was confirmed against a real-world RPKI relying party (NLnet
     Labs Routinator), where concurrent RRDP validation workers parsing a crafted
     `snapshot.xml` exceeded the memory limit and the process was OOM-killed.
     
     ## Affected code paths
     
     Consumers using `NsReader` (which always calls `NamespaceResolver::push` before
     yielding `Start`/`Empty`), or calling `NamespaceResolver::push` directly. A plain
     `Reader` that does not perform namespace resolution is not affected.
     
     ## Remediation
     
     Upgrade to `quick-xml >= 0.41.0`. `NamespaceResolver::push` now rejects a start
     tag that declares more than `DEFAULT_MAX_DECLARATIONS_PER_ELEMENT` (256)
     namespace bindings, returning the new `NamespaceError::TooManyDeclarations`
     instead of allocating without limit. The limit is configurable via
     `NamespaceResolver::set_max_declarations_per_element` (use `usize::MAX` to
     restore the previous unbounded behavior), and `NsReader::resolver_mut()` is
     provided to reach it.
     
     There is no clean workaround for `NsReader` consumers before 0.41.0, as the
     allocation happens inside the reader with no configuration knob to cap it.
   ├ Announcement: https://github.com/tafia/quick-xml/issues/970
   ├ Solution: Upgrade to >=0.41.0 (try `cargo update -p quick-xml`)
   ├ quick-xml v0.37.5
     └── tools v40.0.0
         └── builder v40.0.0

error[unsound]: Rand is unsound with a custom logger using `rand::rng()`
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:84:1
   │
84 │ 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](https://github.com/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
     └── (dev) libdd-common v5.1.0
         ├── builder v40.0.0
         └── tools v40.0.0
             └── builder v40.0.0 (*)

advisories FAILED, bans ok, sources ok

📦 datadog-live-debugger - 3 error(s)

Show output 
error[vulnerability]: Invalid pointer dereference in `fmt::Pointer` impl for `Atomic` and `Shared` when the underlying pointer is invalid
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:76:1
   │
76 │ crossbeam-epoch 0.9.18 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0204
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0204
   ├ Affected versions of `fmt::Display` dereference the underlying pointer. This causes a invalid pointer dereference e.g., when a pointer created with `Atomic::null` or `Shared::null`. `fmt::Debug` impls and pre-0.9 `fmt::Display` impls, which do not dereference pointers, are not affected by this issue.
   ├ Announcement: https://github.com/crossbeam-rs/crossbeam/pull/1276
   ├ Solution: Upgrade to >=0.9.20 (try `cargo update -p crossbeam-epoch`)
   ├ crossbeam-epoch v0.9.18
     └── crossbeam-deque v0.8.5
         └── rayon-core v1.12.1
             └── rayon v1.10.0
                 └── criterion v0.5.1
                     ├── libdd-common v5.1.0
                     │   ├── datadog-live-debugger v0.0.1
                     │   ├── libdd-capabilities-impl v3.0.0
                     │   │   ├── datadog-live-debugger v0.0.1 (*)
                     │   │   ├── libdd-data-pipeline v7.0.0
                     │   │   │   └── datadog-live-debugger v0.0.1 (*)
                     │   │   ├── libdd-remote-config v2.0.0
                     │   │   │   ├── datadog-live-debugger v0.0.1 (*)
                     │   │   │   └── (dev) libdd-remote-config v2.0.0 (*)
                     │   │   ├── libdd-shared-runtime v2.0.0
                     │   │   │   ├── libdd-data-pipeline v7.0.0 (*)
                     │   │   │   ├── libdd-dogstatsd-client v4.0.0
                     │   │   │   │   ├── libdd-data-pipeline v7.0.0 (*)
                     │   │   │   │   └── libdd-trace-stats v6.0.0
                     │   │   │   │       └── libdd-data-pipeline v7.0.0 (*)
                     │   │   │   ├── libdd-telemetry v6.0.0
                     │   │   │   │   ├── libdd-data-pipeline v7.0.0 (*)
                     │   │   │   │   └── libdd-trace-stats v6.0.0 (*)
                     │   │   │   └── libdd-trace-stats v6.0.0 (*)
                     │   │   ├── (dev) libdd-telemetry v6.0.0 (*)
                     │   │   ├── libdd-trace-stats v6.0.0 (*)
                     │   │   └── libdd-trace-utils v9.0.0
                     │   │       ├── libdd-data-pipeline v7.0.0 (*)
                     │   │       ├── libdd-trace-obfuscation v5.0.0
                     │   │       │   └── libdd-trace-stats v6.0.0 (*)
                     │   │       ├── libdd-trace-stats v6.0.0 (*)
                     │   │       └── (dev) libdd-trace-utils v9.0.0 (*)
                     │   ├── libdd-data-pipeline v7.0.0 (*)
                     │   ├── libdd-dogstatsd-client v4.0.0 (*)
                     │   ├── libdd-remote-config v2.0.0 (*)
                     │   ├── libdd-shared-runtime v2.0.0 (*)
                     │   ├── libdd-telemetry v6.0.0 (*)
                     │   ├── libdd-trace-obfuscation v5.0.0 (*)
                     │   ├── libdd-trace-stats v6.0.0 (*)
                     │   └── libdd-trace-utils v9.0.0 (*)
                     ├── (dev) libdd-data-pipeline v7.0.0 (*)
                     ├── (dev) libdd-ddsketch v1.1.0
                     │   ├── libdd-data-pipeline v7.0.0 (*)
                     │   ├── libdd-telemetry v6.0.0 (*)
                     │   └── libdd-trace-stats v6.0.0 (*)
                     ├── (dev) libdd-trace-normalization v3.0.0
                     │   ├── libdd-data-pipeline v7.0.0 (*)
                     │   └── libdd-trace-utils v9.0.0 (*)
                     ├── (dev) libdd-trace-obfuscation v5.0.0 (*)
                     ├── (dev) libdd-trace-stats v6.0.0 (*)
                     └── (dev) libdd-trace-utils v9.0.0 (*)

error[unsound]: Rand is unsound with a custom logger using `rand::rng()`
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:228:1
    │
228 │ 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](https://github.com/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 v5.1.0
      │   ├── datadog-live-debugger v0.0.1
      │   ├── libdd-capabilities-impl v3.0.0
      │   │   ├── datadog-live-debugger v0.0.1 (*)
      │   │   ├── libdd-data-pipeline v7.0.0
      │   │   │   └── datadog-live-debugger v0.0.1 (*)
      │   │   ├── libdd-remote-config v2.0.0
      │   │   │   ├── datadog-live-debugger v0.0.1 (*)
      │   │   │   └── (dev) libdd-remote-config v2.0.0 (*)
      │   │   ├── libdd-shared-runtime v2.0.0
      │   │   │   ├── libdd-data-pipeline v7.0.0 (*)
      │   │   │   ├── libdd-dogstatsd-client v4.0.0
      │   │   │   │   ├── libdd-data-pipeline v7.0.0 (*)
      │   │   │   │   └── libdd-trace-stats v6.0.0
      │   │   │   │       └── libdd-data-pipeline v7.0.0 (*)
      │   │   │   ├── libdd-telemetry v6.0.0
      │   │   │   │   ├── libdd-data-pipeline v7.0.0 (*)
      │   │   │   │   └── libdd-trace-stats v6.0.0 (*)
      │   │   │   └── libdd-trace-stats v6.0.0 (*)
      │   │   ├── (dev) libdd-telemetry v6.0.0 (*)
      │   │   ├── libdd-trace-stats v6.0.0 (*)
      │   │   └── libdd-trace-utils v9.0.0
      │   │       ├── libdd-data-pipeline v7.0.0 (*)
      │   │       ├── libdd-trace-obfuscation v5.0.0
      │   │       │   └── libdd-trace-stats v6.0.0 (*)
      │   │       ├── libdd-trace-stats v6.0.0 (*)
      │   │       └── (dev) libdd-trace-utils v9.0.0 (*)
      │   ├── libdd-data-pipeline v7.0.0 (*)
      │   ├── libdd-dogstatsd-client v4.0.0 (*)
      │   ├── libdd-remote-config v2.0.0 (*)
      │   ├── libdd-shared-runtime v2.0.0 (*)
      │   ├── libdd-telemetry v6.0.0 (*)
      │   ├── libdd-trace-obfuscation v5.0.0 (*)
      │   ├── libdd-trace-stats v6.0.0 (*)
      │   └── libdd-trace-utils v9.0.0 (*)
      ├── (dev) libdd-data-pipeline v7.0.0 (*)
      ├── (dev) libdd-ddsketch v1.1.0
      │   ├── libdd-data-pipeline v7.0.0 (*)
      │   ├── libdd-telemetry v6.0.0 (*)
      │   └── libdd-trace-stats v6.0.0 (*)
      ├── (dev) libdd-trace-normalization v3.0.0
      │   ├── libdd-data-pipeline v7.0.0 (*)
      │   └── libdd-trace-utils v9.0.0 (*)
      ├── (dev) libdd-trace-stats v6.0.0 (*)
      ├── libdd-trace-utils v9.0.0 (*)
      └── proptest v1.5.0
          └── (dev) libdd-tinybytes v1.1.1
              ├── libdd-data-pipeline v7.0.0 (*)
              ├── (dev) libdd-tinybytes v1.1.1 (*)
              └── libdd-trace-utils v9.0.0 (*)

error[vulnerability]: Denial of Service via Stack Exhaustion
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:303:1
    │
303 │ time 0.3.41 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
    │
    ├ ID: RUSTSEC-2026-0009
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0009
    ├ ## Impact
      
      When user-provided input is provided to any type that parses with the RFC 2822 format, a denial of
      service attack via stack exhaustion is possible. The attack relies on formally deprecated and
      rarely-used features that are part of the RFC 2822 format used in a malicious manner. Ordinary,
      non-malicious input will never encounter this scenario.
      
      ## Patches
      
      A limit to the depth of recursion was added in v0.3.47. From this version, an error will be returned
      rather than exhausting the stack.
      
      ## Workarounds
      
      Limiting the length of user input is the simplest way to avoid stack exhaustion, as the amount of
      the stack consumed would be at most a factor of the length of the input.
    ├ Announcement: https://github.com/time-rs/time/blob/main/CHANGELOG.md#0347-2026-02-05
    ├ Solution: Upgrade to >=0.3.47 (try `cargo update -p time`)
    ├ time v0.3.41
      ├── libdd-remote-config v2.0.0
      │   ├── datadog-live-debugger v0.0.1
      │   └── (dev) libdd-remote-config v2.0.0 (*)
      └── tracing-appender v0.2.3
          └── libdd-log v1.0.0
              └── (dev) libdd-data-pipeline v7.0.0
                  └── datadog-live-debugger v0.0.1 (*)

advisories FAILED, bans ok, sources ok

📦 libdd-crashtracker - 2 error(s)

Show output 
error[vulnerability]: Invalid pointer dereference in `fmt::Pointer` impl for `Atomic` and `Shared` when the underlying pointer is invalid
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:59:1
   │
59 │ crossbeam-epoch 0.9.18 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0204
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0204
   ├ Affected versions of `fmt::Display` dereference the underlying pointer. This causes a invalid pointer dereference e.g., when a pointer created with `Atomic::null` or `Shared::null`. `fmt::Debug` impls and pre-0.9 `fmt::Display` impls, which do not dereference pointers, are not affected by this issue.
   ├ Announcement: https://github.com/crossbeam-rs/crossbeam/pull/1276
   ├ Solution: Upgrade to >=0.9.20 (try `cargo update -p crossbeam-epoch`)
   ├ crossbeam-epoch v0.9.18
     └── crossbeam-deque v0.8.5
         └── rayon-core v1.12.1
             └── rayon v1.10.0
                 └── criterion v0.5.1
                     ├── (dev) libdd-crashtracker v1.0.0
                     └── (dev) libdd-ddsketch v1.1.0
                         └── libdd-telemetry v6.0.0
                             └── libdd-crashtracker v1.0.0 (*)

error[unsound]: Rand is unsound with a custom logger using `rand::rng()`
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:205:1
    │
205 │ 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](https://github.com/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 v5.1.0
      │   ├── libdd-capabilities-impl v3.0.0
      │   │   ├── libdd-crashtracker v1.0.0
      │   │   ├── libdd-shared-runtime v2.0.0
      │   │   │   └── libdd-telemetry v6.0.0
      │   │   │       └── libdd-crashtracker v1.0.0 (*)
      │   │   └── (dev) libdd-telemetry v6.0.0 (*)
      │   ├── (build) libdd-crashtracker v1.0.0 (*)
      │   ├── libdd-shared-runtime v2.0.0 (*)
      │   └── libdd-telemetry v6.0.0 (*)
      ├── libdd-crashtracker v1.0.0 (*)
      └── (dev) libdd-ddsketch v1.1.0
          └── libdd-telemetry v6.0.0 (*)

advisories FAILED, bans ok, sources ok

📦 libdd-ffe - 3 error(s)

Show output 
error[unmaintained]: Bincode is unmaintained
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:22:1
   │
22 │ bincode 1.3.3 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ unmaintained advisory detected
   │
   ├ ID: RUSTSEC-2025-0141
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2025-0141
   ├ Due to a doxxing and harassment incident, the bincode team has taken the decision to cease development permanently.
     
     The team considers version 1.3.3 a complete version of bincode that is not in need of any updates.
     
     ## Alternatives to consider
     
     * [wincode](https://crates.io/crates/wincode)
     * [postcard](https://crates.io/crates/postcard)
     * [bitcode](https://crates.io/crates/bitcode)
     * [rkyv](https://crates.io/crates/rkyv)
   ├ Announcement: https://git.sr.ht/~stygianentity/bincode/tree/v3.0/item/README.md
   ├ Solution: No safe upgrade is available!
   ├ bincode v1.3.3
     └── (dev) libdd-ffe v0.1.0

error[unsound]: Rand is unsound with a custom logger using `rand::rng()`
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:160:1
    │
160 │ 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](https://github.com/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
      └── (dev) libdd-common v5.1.0
          ├── libdd-capabilities-impl v3.0.0
          │   ├── (dev) libdd-ffe v0.1.0
          │   └── libdd-remote-config v2.0.0
          │       ├── libdd-ffe v0.1.0 (*)
          │       └── (dev) libdd-remote-config v2.0.0 (*)
          ├── libdd-ffe v0.1.0 (*)
          └── libdd-remote-config v2.0.0 (*)

error[vulnerability]: Denial of Service via Stack Exhaustion
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:219:1
    │
219 │ time 0.3.41 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
    │
    ├ ID: RUSTSEC-2026-0009
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0009
    ├ ## Impact
      
      When user-provided input is provided to any type that parses with the RFC 2822 format, a denial of
      service attack via stack exhaustion is possible. The attack relies on formally deprecated and
      rarely-used features that are part of the RFC 2822 format used in a malicious manner. Ordinary,
      non-malicious input will never encounter this scenario.
      
      ## Patches
      
      A limit to the depth of recursion was added in v0.3.47. From this version, an error will be returned
      rather than exhausting the stack.
      
      ## Workarounds
      
      Limiting the length of user input is the simplest way to avoid stack exhaustion, as the amount of
      the stack consumed would be at most a factor of the length of the input.
    ├ Announcement: https://github.com/time-rs/time/blob/main/CHANGELOG.md#0347-2026-02-05
    ├ Solution: Upgrade to >=0.3.47 (try `cargo update -p time`)
    ├ time v0.3.41
      └── libdd-remote-config v2.0.0
          ├── libdd-ffe v0.1.0
          └── (dev) libdd-remote-config v2.0.0 (*)

advisories FAILED, bans ok, sources ok

📦 libdd-profiling - 4 error(s)

Show output 
error[vulnerability]: Invalid pointer dereference in `fmt::Pointer` impl for `Atomic` and `Shared` when the underlying pointer is invalid
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:48:1
   │
48 │ crossbeam-epoch 0.9.18 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0204
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0204
   ├ Affected versions of `fmt::Display` dereference the underlying pointer. This causes a invalid pointer dereference e.g., when a pointer created with `Atomic::null` or `Shared::null`. `fmt::Debug` impls and pre-0.9 `fmt::Display` impls, which do not dereference pointers, are not affected by this issue.
   ├ Announcement: https://github.com/crossbeam-rs/crossbeam/pull/1276
   ├ Solution: Upgrade to >=0.9.20 (try `cargo update -p crossbeam-epoch`)
   ├ crossbeam-epoch v0.9.18
     ├── crossbeam-deque v0.8.5
     │   └── rayon-core v1.12.1
     │       └── rayon v1.10.0
     │           └── criterion v0.5.1
     │               └── (dev) libdd-profiling v1.0.0
     │                   └── (dev) libdd-profiling v1.0.0 (*)
     └── moka v0.12.13
         └── hickory-resolver v0.25.2
             └── reqwest v0.13.2
                 ├── libdd-common v5.1.0
                 │   └── libdd-profiling v1.0.0 (*)
                 └── libdd-profiling v1.0.0 (*)

error[vulnerability]: NSEC3 closest-encloser proof validation enters unbounded loop on cross-zone responses
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:78:1
   │
78 │ 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 v5.1.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:78:1
   │
78 │ 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 v5.1.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:156:1
    │
156 │ 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](https://github.com/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 v5.1.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 (*)

advisories FAILED, bans ok, sources ok

Updated: 2026-08-07 12:39:54 UTC | Commit: 9dcdb5a | dependency-check job results

@pr-commenter

pr-commenter Bot commented Aug 7, 2026 •
edited
Loading

Copy link
Copy Markdown

Benchmarks

Comparison

Benchmark execution time: 2026-08-07 12:45:21

Comparing candidate commit dd7136d in PR branch levi/slow-miri with baseline commit ea75b04 in branch main.

Found 0 performance improvements and 1 performance regressions! Performance is the same for 12 metrics, 0 unstable metrics.

Explanation

This is an A/B test comparing a candidate commit's performance against that of a baseline commit. Performance changes are noted in the tables below as:

  • 🟩 = significantly better candidate vs. baseline
  • 🟥 = significantly worse candidate vs. baseline

We compute a confidence interval (CI) over the relative difference of means between metrics from the candidate and baseline commits, considering the baseline as the reference.

If the CI is entirely outside the configured SIGNIFICANT_IMPACT_THRESHOLD (or the deprecated UNCONFIDENCE_THRESHOLD), the change is considered significant.

Feel free to reach out to #apm-benchmarking-platform on Slack if you have any questions.

More details about the CI and significant changes

You can imagine this CI as a range of values that is likely to contain the true difference of means between the candidate and baseline commits.

CIs of the difference of means are often centered around 0%, because often changes are not that big:

---------------------------------(------|---^--------)-------------------------------->
                              -0.6%    0%  0.3%     +1.2%
                                 |          |        |
         lower bound of the CI --'          |        |
sample mean (center of the CI) -------------'        |
         upper bound of the CI ----------------------'

As described above, a change is considered significant if the CI is entirely outside the configured SIGNIFICANT_IMPACT_THRESHOLD (or the deprecated UNCONFIDENCE_THRESHOLD).

For instance, for an execution time metric, this confidence interval indicates a significantly worse performance:

----------------------------------------|---------|---(---------^---------)---------->
                                       0%        1%  1.3%      2.2%      3.1%
                                                  |   |         |         |
       significant impact threshold --------------'   |         |         |
                      lower bound of CI --------------'         |         |
       sample mean (center of the CI) --------------------------'         |
                      upper bound of CI ----------------------------------'

scenario:profile_add_sample_timestamped_x1000

  • 🟥 execution_time [+204.371µs; +207.982µs] or [+5.075%; +5.164%]

Benchmark execution time: 2026-08-07 12:25:33

Comparing candidate commit dd7136d in PR branch levi/slow-miri with baseline commit ea75b04 in branch main.

Found 0 performance improvements and 0 performance regressions! Performance is the same for 14 metrics, 0 unstable metrics.

Explanation

This is an A/B test comparing a candidate commit's performance against that of a baseline commit. Performance changes are noted in the tables below as:

  • 🟩 = significantly better candidate vs. baseline
  • 🟥 = significantly worse candidate vs. baseline

We compute a confidence interval (CI) over the relative difference of means between metrics from the candidate and baseline commits, considering the baseline as the reference.

If the CI is entirely outside the configured SIGNIFICANT_IMPACT_THRESHOLD (or the deprecated UNCONFIDENCE_THRESHOLD), the change is considered significant.

Feel free to reach out to #apm-benchmarking-platform on Slack if you have any questions.

More details about the CI and significant changes

You can imagine this CI as a range of values that is likely to contain the true difference of means between the candidate and baseline commits.

CIs of the difference of means are often centered around 0%, because often changes are not that big:

---------------------------------(------|---^--------)-------------------------------->
                              -0.6%    0%  0.3%     +1.2%
                                 |          |        |
         lower bound of the CI --'          |        |
sample mean (center of the CI) -------------'        |
         upper bound of the CI ----------------------'

As described above, a change is considered significant if the CI is entirely outside the configured SIGNIFICANT_IMPACT_THRESHOLD (or the deprecated UNCONFIDENCE_THRESHOLD).

For instance, for an execution time metric, this confidence interval indicates a significantly worse performance:

----------------------------------------|---------|---(---------^---------)---------->
                                       0%        1%  1.3%      2.2%      3.1%
                                                  |   |         |         |
       significant impact threshold --------------'   |         |         |
                      lower bound of CI --------------'         |         |
       sample mean (center of the CI) --------------------------'         |
                      upper bound of CI ----------------------------------'

Candidate

Candidate benchmark details

Group 1

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8175M CPU @ 2.50GHz dd7136d 1786104879 levi/slow-miri
scenario metric min mean ± sd median ± mad p75 p95 p99 max peak_to_median_ratio skewness kurtosis cv sem runs sample_size
benching string interning on wordpress profile execution_time 125.783µs 127.428µs ± 0.447µs 127.413µs ± 0.146µs 127.547µs 127.955µs 129.521µs 130.017µs 2.04% 1.941 11.606 0.35% 0.032µs 1 200
scenario metric 95% CI mean Shapiro-Wilk pvalue Ljung-Box pvalue (lag=1) Dip test pvalue
benching string interning on wordpress profile execution_time [127.366µs; 127.490µs] or [-0.049%; +0.049%] None None None

Group 2

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8175M CPU @ 2.50GHz dd7136d 1786104879 levi/slow-miri
scenario metric min mean ± sd median ± mad p75 p95 p99 max peak_to_median_ratio skewness kurtosis cv sem runs sample_size
profile_add_sample_frames_x1000 execution_time 4.211ms 4.217ms ± 0.003ms 4.217ms ± 0.002ms 4.218ms 4.221ms 4.224ms 4.238ms 0.51% 1.989 11.890 0.07% 0.000ms 1 200
scenario metric 95% CI mean Shapiro-Wilk pvalue Ljung-Box pvalue (lag=1) Dip test pvalue
profile_add_sample_frames_x1000 execution_time [4.216ms; 4.217ms] or [-0.010%; +0.010%] None None None

Group 3

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8175M CPU @ 2.50GHz dd7136d 1786104879 levi/slow-miri
scenario metric min mean ± sd median ± mad p75 p95 p99 max peak_to_median_ratio skewness kurtosis cv sem runs sample_size
profile_serialize_compressed_pprof_timestamped_x1000 execution_time 909.784µs 916.202µs ± 2.679µs 915.625µs ± 1.101µs 917.091µs 921.456µs 923.410µs 925.585µs 1.09% 0.562 1.221 0.29% 0.189µs 1 200
scenario metric 95% CI mean Shapiro-Wilk pvalue Ljung-Box pvalue (lag=1) Dip test pvalue
profile_serialize_compressed_pprof_timestamped_x1000 execution_time [915.830µs; 916.573µs] or [-0.041%; +0.041%] None None None

Group 4

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8175M CPU @ 2.50GHz dd7136d 1786104879 levi/slow-miri
scenario metric min mean ± sd median ± mad p75 p95 p99 max peak_to_median_ratio skewness kurtosis cv sem runs sample_size
profiles_dictionary/profile_string_inserts/threads/1 execution_time 398.098µs 400.417µs ± 1.497µs 400.419µs ± 1.312µs 401.908µs 402.084µs 402.100µs 402.105µs 0.42% -0.129 -1.509 0.35% 0.473µs 1 10
profiles_dictionary/profile_string_inserts/threads/1 throughput 2546601.459op/s 2557364.123op/s ± 9567.190op/s 2557324.194op/s ± 8400.628op/s 2564830.073op/s 2569667.399op/s 2571716.124op/s 2572228.306op/s 0.58% 0.134 -1.504 0.35% 3025.411op/s 1 10
profiles_dictionary/profile_string_inserts/threads/16 execution_time 2.015ms 2.026ms ± 0.009ms 2.024ms ± 0.007ms 2.034ms 2.038ms 2.039ms 2.039ms 0.74% 0.368 -1.484 0.44% 0.003ms 1 10
profiles_dictionary/profile_string_inserts/threads/16 throughput 8036501.093op/s 8088862.299op/s ± 37806.632op/s 8096304.060op/s ± 26191.027op/s 8121334.159op/s 8128007.804op/s 8131248.478op/s 8132058.647op/s 0.44% -0.363 -1.486 0.44% 11955.507op/s 1 10
profiles_dictionary/profile_string_inserts/threads/2 execution_time 672.866µs 674.263µs ± 1.057µs 674.076µs ± 0.799µs 675.327µs 675.599µs 675.626µs 675.633µs 0.23% 0.166 -1.547 0.15% 0.334µs 1 10
profiles_dictionary/profile_string_inserts/threads/2 throughput 3031233.634op/s 3037398.206op/s ± 4758.670op/s 3038231.569op/s ± 3599.883op/s 3041361.186op/s 3042913.923op/s 3043538.501op/s 3043694.645op/s 0.18% -0.164 -1.547 0.15% 1504.823op/s 1 10
profiles_dictionary/profile_string_inserts/threads/4 execution_time 841.057µs 843.770µs ± 3.012µs 843.329µs ± 1.219µs 844.081µs 848.518µs 850.976µs 851.591µs 0.98% 1.865 2.766 0.34% 0.953µs 1 10
profiles_dictionary/profile_string_inserts/threads/4 throughput 4809823.132op/s 4854458.210op/s ± 17223.222op/s 4856939.891op/s ± 7014.980op/s 4864716.336op/s 4869228.129op/s 4869896.294op/s 4870063.335op/s 0.27% -1.852 2.731 0.34% 5446.461op/s 1 10
scenario metric 95% CI mean Shapiro-Wilk pvalue Ljung-Box pvalue (lag=1) Dip test pvalue
profiles_dictionary/profile_string_inserts/threads/1 execution_time [399.489µs; 401.345µs] or [-0.232%; +0.232%] None None None
profiles_dictionary/profile_string_inserts/threads/1 throughput [2551434.426op/s; 2563293.820op/s] or [-0.232%; +0.232%] None None None
profiles_dictionary/profile_string_inserts/threads/16 execution_time [2.020ms; 2.031ms] or [-0.290%; +0.290%] None None None
profiles_dictionary/profile_string_inserts/threads/16 throughput [8065429.936op/s; 8112294.662op/s] or [-0.290%; +0.290%] None None None
profiles_dictionary/profile_string_inserts/threads/2 execution_time [673.608µs; 674.918µs] or [-0.097%; +0.097%] None None None
profiles_dictionary/profile_string_inserts/threads/2 throughput [3034448.807op/s; 3040347.606op/s] or [-0.097%; +0.097%] None None None
profiles_dictionary/profile_string_inserts/threads/4 execution_time [841.903µs; 845.637µs] or [-0.221%; +0.221%] None None None
profiles_dictionary/profile_string_inserts/threads/4 throughput [4843783.342op/s; 4865133.078op/s] or [-0.220%; +0.220%] None None None

Group 5

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8175M CPU @ 2.50GHz dd7136d 1786104879 levi/slow-miri
scenario metric min mean ± sd median ± mad p75 p95 p99 max peak_to_median_ratio skewness kurtosis cv sem runs sample_size
receiver_entry_point/report/2644 execution_time 5.450ms 5.499ms ± 0.022ms 5.498ms ± 0.016ms 5.513ms 5.542ms 5.555ms 5.572ms 1.35% 0.595 0.288 0.40% 0.002ms 1 200
scenario metric 95% CI mean Shapiro-Wilk pvalue Ljung-Box pvalue (lag=1) Dip test pvalue
receiver_entry_point/report/2644 execution_time [5.496ms; 5.502ms] or [-0.056%; +0.056%] None None None

Group 6

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8175M CPU @ 2.50GHz dd7136d 1786104879 levi/slow-miri
scenario metric min mean ± sd median ± mad p75 p95 p99 max peak_to_median_ratio skewness kurtosis cv sem runs sample_size
profile_add_sample_timestamped_x1000 execution_time 4.228ms 4.233ms ± 0.010ms 4.232ms ± 0.001ms 4.234ms 4.237ms 4.244ms 4.364ms 3.11% 11.630 147.856 0.23% 0.001ms 1 200
scenario metric 95% CI mean Shapiro-Wilk pvalue Ljung-Box pvalue (lag=1) Dip test pvalue
profile_add_sample_timestamped_x1000 execution_time [4.232ms; 4.235ms] or [-0.033%; +0.033%] None None None

Group 7

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8175M CPU @ 2.50GHz dd7136d 1786104879 levi/slow-miri
scenario metric min mean ± sd median ± mad p75 p95 p99 max peak_to_median_ratio skewness kurtosis cv sem runs sample_size
profile_add_sample2_frames_x1000 execution_time 702.633µs 704.220µs ± 0.756µs 704.210µs ± 0.459µs 704.609µs 705.231µs 705.977µs 709.486µs 0.75% 1.813 10.922 0.11% 0.053µs 1 200
scenario metric 95% CI mean Shapiro-Wilk pvalue Ljung-Box pvalue (lag=1) Dip test pvalue
profile_add_sample2_frames_x1000 execution_time [704.115µs; 704.324µs] or [-0.015%; +0.015%] None None None

Group 1

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz dd7136d 1786104879 levi/slow-miri
scenario metric min mean ± sd median ± mad p75 p95 p99 max peak_to_median_ratio skewness kurtosis cv sem runs sample_size
single_flag_killswitch/rules-based execution_time 157.212ns 160.822ns ± 3.011ns 160.025ns ± 1.822ns 162.334ns 166.803ns 169.321ns 172.785ns 7.97% 1.187 1.183 1.87% 0.213ns 1 200
scenario metric 95% CI mean Shapiro-Wilk pvalue Ljung-Box pvalue (lag=1) Dip test pvalue
single_flag_killswitch/rules-based execution_time [160.405ns; 161.239ns] or [-0.259%; +0.259%] None None None

Group 2

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz dd7136d 1786104879 levi/slow-miri
scenario metric min mean ± sd median ± mad p75 p95 p99 max peak_to_median_ratio skewness kurtosis cv sem runs sample_size
flagevaluation_evp/payloads/scale/2500flags_500users_20fields execution_time 21.579ms 21.727ms ± 0.061ms 21.722ms ± 0.041ms 21.765ms 21.834ms 21.877ms 21.885ms 0.75% 0.251 -0.237 0.28% 0.004ms 1 200
flagevaluation_evp/payloads/scale/2500flags_500users_20fields throughput 114234.566op/s 115067.542op/s ± 325.254op/s 115090.261op/s ± 219.188op/s 115296.044op/s 115588.035op/s 115707.259op/s 115853.317op/s 0.66% -0.237 -0.246 0.28% 22.999op/s 1 200
flagevaluation_evp/payloads/stress/10flags_1000users_250fields execution_time 95.863ms 96.689ms ± 0.348ms 96.707ms ± 0.199ms 96.888ms 97.159ms 97.769ms 98.672ms 2.03% 0.941 4.991 0.36% 0.025ms 1 200
flagevaluation_evp/payloads/stress/10flags_1000users_250fields throughput 10134.540op/s 10342.613op/s ± 37.061op/s 10340.507op/s ± 21.371op/s 10365.857op/s 10399.413op/s 10426.022op/s 10431.512op/s 0.88% -0.877 4.655 0.36% 2.621op/s 1 200
flagevaluation_evp/payloads/typical/100flags_50users_10fields execution_time 594.940µs 597.452µs ± 0.988µs 597.425µs ± 0.544µs 597.982µs 599.022µs 599.795µs 603.787µs 1.06% 1.256 7.454 0.17% 0.070µs 1 200
flagevaluation_evp/payloads/typical/100flags_50users_10fields throughput 165621.367op/s 167377.787op/s ± 276.351op/s 167385.062op/s ± 152.367op/s 167534.228op/s 167794.170op/s 167945.769op/s 168084.225op/s 0.42% -1.217 7.195 0.16% 19.541op/s 1 200
scenario metric 95% CI mean Shapiro-Wilk pvalue Ljung-Box pvalue (lag=1) Dip test pvalue
flagevaluation_evp/payloads/scale/2500flags_500users_20fields execution_time [21.718ms; 21.735ms] or [-0.039%; +0.039%] None None None
flagevaluation_evp/payloads/scale/2500flags_500users_20fields throughput [115022.465op/s; 115112.619op/s] or [-0.039%; +0.039%] None None None
flagevaluation_evp/payloads/stress/10flags_1000users_250fields execution_time [96.640ms; 96.737ms] or [-0.050%; +0.050%] None None None
flagevaluation_evp/payloads/stress/10flags_1000users_250fields throughput [10337.477op/s; 10347.749op/s] or [-0.050%; +0.050%] None None None
flagevaluation_evp/payloads/typical/100flags_50users_10fields execution_time [597.315µs; 597.589µs] or [-0.023%; +0.023%] None None None
flagevaluation_evp/payloads/typical/100flags_50users_10fields throughput [167339.488op/s; 167416.087op/s] or [-0.023%; +0.023%] None None None

Group 3

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz dd7136d 1786104879 levi/slow-miri
scenario metric min mean ± sd median ± mad p75 p95 p99 max peak_to_median_ratio skewness kurtosis cv sem runs sample_size
sdk_test_data/rules-based execution_time 124.443µs 127.331µs ± 5.173µs 126.311µs ± 0.607µs 126.981µs 131.343µs 148.041µs 182.340µs 44.36% 7.521 68.538 4.05% 0.366µs 1 200
scenario metric 95% CI mean Shapiro-Wilk pvalue Ljung-Box pvalue (lag=1) Dip test pvalue
sdk_test_data/rules-based execution_time [126.614µs; 128.048µs] or [-0.563%; +0.563%] None None None

Group 4

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz dd7136d 1786104879 levi/slow-miri
scenario metric min mean ± sd median ± mad p75 p95 p99 max peak_to_median_ratio skewness kurtosis cv sem runs sample_size
flagevaluation_evp/coalescer/scale/2500flags_500users_20fields execution_time 5.347ms 5.365ms ± 0.020ms 5.364ms ± 0.005ms 5.369ms 5.376ms 5.382ms 5.626ms 4.89% 11.314 146.077 0.37% 0.001ms 1 200
flagevaluation_evp/coalescer/scale/2500flags_500users_20fields throughput 444344.062op/s 465991.115op/s ± 1662.581op/s 466085.824op/s ± 429.826op/s 466553.568op/s 467265.866op/s 467444.679op/s 467570.830op/s 0.32% -11.089 142.203 0.36% 117.562op/s 1 200
flagevaluation_evp/coalescer/stress/10flags_1000users_250fields execution_time 7.927ms 7.940ms ± 0.007ms 7.940ms ± 0.004ms 7.944ms 7.949ms 7.974ms 7.978ms 0.48% 2.001 8.976 0.09% 0.000ms 1 200
flagevaluation_evp/coalescer/stress/10flags_1000users_250fields throughput 125343.996op/s 125942.269op/s ± 110.171op/s 125951.281op/s ± 60.098op/s 126003.815op/s 126089.318op/s 126139.645op/s 126157.145op/s 0.16% -1.983 8.867 0.09% 7.790op/s 1 200
flagevaluation_evp/coalescer/typical/100flags_50users_10fields execution_time 180.598µs 184.877µs ± 38.877µs 182.067µs ± 0.176µs 182.317µs 182.815µs 183.084µs 731.914µs 302.00% 14.034 194.975 20.98% 2.749µs 1 200
flagevaluation_evp/coalescer/typical/100flags_50users_10fields throughput 136627.980op/s 547002.670op/s ± 29181.412op/s 549248.601op/s ± 530.317op/s 549707.506op/s 550194.365op/s 550462.551op/s 553715.681op/s 0.81% -14.010 194.525 5.32% 2063.437op/s 1 200
scenario metric 95% CI mean Shapiro-Wilk pvalue Ljung-Box pvalue (lag=1) Dip test pvalue
flagevaluation_evp/coalescer/scale/2500flags_500users_20fields execution_time [5.362ms; 5.368ms] or [-0.051%; +0.051%] None None None
flagevaluation_evp/coalescer/scale/2500flags_500users_20fields throughput [465760.697op/s; 466221.532op/s] or [-0.049%; +0.049%] None None None
flagevaluation_evp/coalescer/stress/10flags_1000users_250fields execution_time [7.939ms; 7.941ms] or [-0.012%; +0.012%] None None None
flagevaluation_evp/coalescer/stress/10flags_1000users_250fields throughput [125927.000op/s; 125957.537op/s] or [-0.012%; +0.012%] None None None
flagevaluation_evp/coalescer/typical/100flags_50users_10fields execution_time [179.489µs; 190.265µs] or [-2.914%; +2.914%] None None None
flagevaluation_evp/coalescer/typical/100flags_50users_10fields throughput [542958.407op/s; 551046.934op/s] or [-0.739%; +0.739%] None None None

Baseline

Baseline benchmark details

Group 1

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8175M CPU @ 2.50GHz ea75b04 1786079201 main
scenario metric min mean ± sd median ± mad p75 p95 p99 max peak_to_median_ratio skewness kurtosis cv sem runs sample_size
benching string interning on wordpress profile execution_time 124.808µs 125.776µs ± 0.622µs 125.912µs ± 0.350µs 126.117µs 126.510µs 127.672µs 130.163µs 3.38% 1.812 11.294 0.49% 0.044µs 1 200
scenario metric 95% CI mean Shapiro-Wilk pvalue Ljung-Box pvalue (lag=1) Dip test pvalue
benching string interning on wordpress profile execution_time [125.690µs; 125.862µs] or [-0.069%; +0.069%] None None None

Group 2

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8175M CPU @ 2.50GHz ea75b04 1786079201 main
scenario metric min mean ± sd median ± mad p75 p95 p99 max peak_to_median_ratio skewness kurtosis cv sem runs sample_size
profile_add_sample_frames_x1000 execution_time 4.064ms 4.069ms ± 0.003ms 4.069ms ± 0.001ms 4.071ms 4.073ms 4.074ms 4.091ms 0.54% 3.081 21.878 0.06% 0.000ms 1 200
scenario metric 95% CI mean Shapiro-Wilk pvalue Ljung-Box pvalue (lag=1) Dip test pvalue
profile_add_sample_frames_x1000 execution_time [4.069ms; 4.070ms] or [-0.009%; +0.009%] None None None

Group 3

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8175M CPU @ 2.50GHz ea75b04 1786079201 main
scenario metric min mean ± sd median ± mad p75 p95 p99 max peak_to_median_ratio skewness kurtosis cv sem runs sample_size
profile_serialize_compressed_pprof_timestamped_x1000 execution_time 919.358µs 925.577µs ± 3.999µs 925.067µs ± 1.102µs 926.270µs 929.452µs 932.715µs 970.635µs 4.93% 7.279 78.997 0.43% 0.283µs 1 200
scenario metric 95% CI mean Shapiro-Wilk pvalue Ljung-Box pvalue (lag=1) Dip test pvalue
profile_serialize_compressed_pprof_timestamped_x1000 execution_time [925.023µs; 926.131µs] or [-0.060%; +0.060%] None None None

Group 4

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8175M CPU @ 2.50GHz ea75b04 1786079201 main
scenario metric min mean ± sd median ± mad p75 p95 p99 max peak_to_median_ratio skewness kurtosis cv sem runs sample_size
profiles_dictionary/profile_string_inserts/threads/1 execution_time 399.295µs 401.069µs ± 0.902µs 401.340µs ± 0.529µs 401.747µs 402.005µs 402.096µs 402.119µs 0.19% -0.706 -0.588 0.21% 0.285µs 1 10
profiles_dictionary/profile_string_inserts/threads/1 throughput 2546509.881op/s 2553190.859op/s ± 5750.547op/s 2551454.163op/s ± 3363.239op/s 2556764.417op/s 2562127.086op/s 2564043.937op/s 2564523.150op/s 0.51% 0.712 -0.578 0.21% 1818.483op/s 1 10
profiles_dictionary/profile_string_inserts/threads/16 execution_time 2.004ms 2.010ms ± 0.007ms 2.008ms ± 0.003ms 2.010ms 2.022ms 2.022ms 2.022ms 0.72% 1.170 -0.189 0.31% 0.002ms 1 10
profiles_dictionary/profile_string_inserts/threads/16 throughput 8101008.701op/s 8150924.889op/s ± 26759.420op/s 8159067.732op/s ± 11284.462op/s 8169612.180op/s 8173346.154op/s 8173982.711op/s 8174141.850op/s 0.18% -1.166 -0.195 0.31% 8462.072op/s 1 10
profiles_dictionary/profile_string_inserts/threads/2 execution_time 672.025µs 675.563µs ± 5.400µs 674.117µs ± 1.845µs 675.448µs 684.627µs 688.800µs 689.843µs 2.33% 2.056 3.126 0.76% 1.708µs 1 10
profiles_dictionary/profile_string_inserts/threads/2 throughput 2968790.596op/s 3031717.307op/s ± 23864.314op/s 3038048.750op/s ± 8338.995op/s 3046616.148op/s 3047507.347op/s 3047507.540op/s 3047507.589op/s 0.31% -2.035 3.061 0.75% 7546.559op/s 1 10
profiles_dictionary/profile_string_inserts/threads/4 execution_time 815.128µs 834.810µs ± 7.476µs 837.084µs ± 1.842µs 838.369µs 840.720µs 842.214µs 842.587µs 0.66% -1.963 3.099 0.85% 2.364µs 1 10
profiles_dictionary/profile_string_inserts/threads/4 throughput 4861216.486op/s 4906863.701op/s ± 44694.128op/s 4893177.439op/s ± 10779.348op/s 4910951.212op/s 4977678.903op/s 5015516.508op/s 5024975.909op/s 2.69% 1.994 3.178 0.86% 14133.524op/s 1 10
scenario metric 95% CI mean Shapiro-Wilk pvalue Ljung-Box pvalue (lag=1) Dip test pvalue
profiles_dictionary/profile_string_inserts/threads/1 execution_time [400.510µs; 401.628µs] or [-0.139%; +0.139%] None None None
profiles_dictionary/profile_string_inserts/threads/1 throughput [2549626.698op/s; 2556755.019op/s] or [-0.140%; +0.140%] None None None
profiles_dictionary/profile_string_inserts/threads/16 execution_time [2.006ms; 2.014ms] or [-0.204%; +0.204%] None None None
profiles_dictionary/profile_string_inserts/threads/16 throughput [8134339.533op/s; 8167510.245op/s] or [-0.203%; +0.203%] None None None
profiles_dictionary/profile_string_inserts/threads/2 execution_time [672.216µs; 678.910µs] or [-0.495%; +0.495%] None None None
profiles_dictionary/profile_string_inserts/threads/2 throughput [3016926.324op/s; 3046508.291op/s] or [-0.488%; +0.488%] None None None
profiles_dictionary/profile_string_inserts/threads/4 execution_time [830.177µs; 839.444µs] or [-0.555%; +0.555%] None None None
profiles_dictionary/profile_string_inserts/threads/4 throughput [4879162.503op/s; 4934564.899op/s] or [-0.565%; +0.565%] None None None

Group 5

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8175M CPU @ 2.50GHz ea75b04 1786079201 main
scenario metric min mean ± sd median ± mad p75 p95 p99 max peak_to_median_ratio skewness kurtosis cv sem runs sample_size
receiver_entry_point/report/2645 execution_time 5.457ms 5.518ms ± 0.034ms 5.511ms ± 0.021ms 5.536ms 5.584ms 5.603ms 5.611ms 1.81% 0.749 -0.101 0.61% 0.002ms 1 200
scenario metric 95% CI mean Shapiro-Wilk pvalue Ljung-Box pvalue (lag=1) Dip test pvalue
receiver_entry_point/report/2645 execution_time [5.514ms; 5.523ms] or [-0.085%; +0.085%] None None None

Group 6

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8175M CPU @ 2.50GHz ea75b04 1786079201 main
scenario metric min mean ± sd median ± mad p75 p95 p99 max peak_to_median_ratio skewness kurtosis cv sem runs sample_size
profile_add_sample_timestamped_x1000 execution_time 4.023ms 4.027ms ± 0.008ms 4.026ms ± 0.001ms 4.028ms 4.031ms 4.035ms 4.138ms 2.78% 11.740 150.158 0.21% 0.001ms 1 200
scenario metric 95% CI mean Shapiro-Wilk pvalue Ljung-Box pvalue (lag=1) Dip test pvalue
profile_add_sample_timestamped_x1000 execution_time [4.026ms; 4.028ms] or [-0.029%; +0.029%] None None None

Group 7

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8175M CPU @ 2.50GHz ea75b04 1786079201 main
scenario metric min mean ± sd median ± mad p75 p95 p99 max peak_to_median_ratio skewness kurtosis cv sem runs sample_size
profile_add_sample2_frames_x1000 execution_time 691.879µs 693.829µs ± 0.617µs 693.810µs ± 0.388µs 694.217µs 694.837µs 695.387µs 696.697µs 0.42% 0.525 2.029 0.09% 0.044µs 1 200
scenario metric 95% CI mean Shapiro-Wilk pvalue Ljung-Box pvalue (lag=1) Dip test pvalue
profile_add_sample2_frames_x1000 execution_time [693.744µs; 693.915µs] or [-0.012%; +0.012%] None None None

Group 1

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz ea75b04 1786079201 main
scenario metric min mean ± sd median ± mad p75 p95 p99 max peak_to_median_ratio skewness kurtosis cv sem runs sample_size
single_flag_killswitch/rules-based execution_time 157.022ns 161.393ns ± 3.490ns 160.654ns ± 1.887ns 162.942ns 168.218ns 172.043ns 176.555ns 9.90% 1.310 1.860 2.16% 0.247ns 1 200
scenario metric 95% CI mean Shapiro-Wilk pvalue Ljung-Box pvalue (lag=1) Dip test pvalue
single_flag_killswitch/rules-based execution_time [160.909ns; 161.876ns] or [-0.300%; +0.300%] None None None

Group 2

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz ea75b04 1786079201 main
scenario metric min mean ± sd median ± mad p75 p95 p99 max peak_to_median_ratio skewness kurtosis cv sem runs sample_size
flagevaluation_evp/payloads/scale/2500flags_500users_20fields execution_time 21.418ms 21.494ms ± 0.032ms 21.494ms ± 0.024ms 21.519ms 21.544ms 21.561ms 21.585ms 0.42% -0.008 -0.548 0.15% 0.002ms 1 200
flagevaluation_evp/payloads/scale/2500flags_500users_20fields throughput 115822.495op/s 116310.425op/s ± 175.471op/s 116310.257op/s ± 128.620op/s 116433.791op/s 116602.889op/s 116645.224op/s 116723.422op/s 0.36% 0.014 -0.550 0.15% 12.408op/s 1 200
flagevaluation_evp/payloads/stress/10flags_1000users_250fields execution_time 95.483ms 96.072ms ± 0.380ms 96.021ms ± 0.208ms 96.261ms 96.546ms 96.650ms 99.567ms 3.69% 3.906 34.058 0.39% 0.027ms 1 200
flagevaluation_evp/payloads/stress/10flags_1000users_250fields throughput 10043.439op/s 10409.038op/s ± 40.539op/s 10414.388op/s ± 22.553op/s 10431.619op/s 10466.447op/s 10471.004op/s 10473.080op/s 0.56% -3.667 31.251 0.39% 2.867op/s 1 200
flagevaluation_evp/payloads/typical/100flags_50users_10fields execution_time 590.707µs 591.894µs ± 0.537µs 591.835µs ± 0.353µs 592.263µs 592.776µs 593.173µs 593.351µs 0.26% 0.350 -0.493 0.09% 0.038µs 1 200
flagevaluation_evp/payloads/typical/100flags_50users_10fields throughput 168534.349op/s 168949.186op/s ± 153.367op/s 168966.030op/s ± 100.688op/s 169059.423op/s 169165.584op/s 169228.939op/s 169288.687op/s 0.19% -0.346 -0.496 0.09% 10.845op/s 1 200
scenario metric 95% CI mean Shapiro-Wilk pvalue Ljung-Box pvalue (lag=1) Dip test pvalue
flagevaluation_evp/payloads/scale/2500flags_500users_20fields execution_time [21.490ms; 21.499ms] or [-0.021%; +0.021%] None None None
flagevaluation_evp/payloads/scale/2500flags_500users_20fields throughput [116286.107op/s; 116334.744op/s] or [-0.021%; +0.021%] None None None
flagevaluation_evp/payloads/stress/10flags_1000users_250fields execution_time [96.019ms; 96.124ms] or [-0.055%; +0.055%] None None None
flagevaluation_evp/payloads/stress/10flags_1000users_250fields throughput [10403.420op/s; 10414.656op/s] or [-0.054%; +0.054%] None None None
flagevaluation_evp/payloads/typical/100flags_50users_10fields execution_time [591.820µs; 591.969µs] or [-0.013%; +0.013%] None None None
flagevaluation_evp/payloads/typical/100flags_50users_10fields throughput [168927.930op/s; 168970.441op/s] or [-0.013%; +0.013%] None None None

Group 3

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz ea75b04 1786079201 main
scenario metric min mean ± sd median ± mad p75 p95 p99 max peak_to_median_ratio skewness kurtosis cv sem runs sample_size
sdk_test_data/rules-based execution_time 123.751µs 126.382µs ± 3.903µs 125.695µs ± 0.627µs 126.361µs 129.466µs 139.646µs 169.265µs 34.66% 7.955 76.829 3.08% 0.276µs 1 200
scenario metric 95% CI mean Shapiro-Wilk pvalue Ljung-Box pvalue (lag=1) Dip test pvalue
sdk_test_data/rules-based execution_time [125.841µs; 126.923µs] or [-0.428%; +0.428%] None None None

Group 4

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz ea75b04 1786079201 main
scenario metric min mean ± sd median ± mad p75 p95 p99 max peak_to_median_ratio skewness kurtosis cv sem runs sample_size
flagevaluation_evp/coalescer/scale/2500flags_500users_20fields execution_time 5.349ms 5.366ms ± 0.021ms 5.364ms ± 0.004ms 5.369ms 5.378ms 5.382ms 5.653ms 5.39% 12.084 159.313 0.40% 0.002ms 1 200
flagevaluation_evp/coalescer/scale/2500flags_500users_20fields throughput 442232.652op/s 465882.239op/s ± 1775.479op/s 466056.065op/s ± 351.882op/s 466393.251op/s 466813.873op/s 467021.490op/s 467355.953op/s 0.28% -11.899 156.016 0.38% 125.545op/s 1 200
flagevaluation_evp/coalescer/stress/10flags_1000users_250fields execution_time 7.928ms 7.965ms ± 0.013ms 7.965ms ± 0.008ms 7.973ms 7.984ms 7.996ms 8.018ms 0.66% -0.103 1.138 0.17% 0.001ms 1 200
flagevaluation_evp/coalescer/stress/10flags_1000users_250fields throughput 124721.627op/s 125557.089op/s ± 210.094op/s 125549.930op/s ± 131.429op/s 125680.421op/s 125955.020op/s 126090.883op/s 126134.708op/s 0.47% 0.119 1.121 0.17% 14.856op/s 1 200
flagevaluation_evp/coalescer/typical/100flags_50users_10fields execution_time 180.054µs 185.725µs ± 39.284µs 182.946µs ± 0.142µs 183.097µs 183.498µs 184.283µs 738.471µs 303.66% 14.033 194.946 21.10% 2.778µs 1 200
flagevaluation_evp/coalescer/typical/100flags_50users_10fields throughput 135414.932op/s 544551.873op/s ± 29111.630op/s 546609.950op/s ± 424.807op/s 547004.515op/s 547711.102op/s 554361.497op/s 555388.553op/s 1.61% -13.983 194.030 5.33% 2058.503op/s 1 200
scenario metric 95% CI mean Shapiro-Wilk pvalue Ljung-Box pvalue (lag=1) Dip test pvalue
flagevaluation_evp/coalescer/scale/2500flags_500users_20fields execution_time [5.363ms; 5.369ms] or [-0.055%; +0.055%] None None None
flagevaluation_evp/coalescer/scale/2500flags_500users_20fields throughput [465636.175op/s; 466128.304op/s] or [-0.053%; +0.053%] None None None
flagevaluation_evp/coalescer/stress/10flags_1000users_250fields execution_time [7.963ms; 7.966ms] or [-0.023%; +0.023%] None None None
flagevaluation_evp/coalescer/stress/10flags_1000users_250fields throughput [125527.972op/s; 125586.206op/s] or [-0.023%; +0.023%] None None None
flagevaluation_evp/coalescer/typical/100flags_50users_10fields execution_time [180.281µs; 191.170µs] or [-2.931%; +2.931%] None None None
flagevaluation_evp/coalescer/typical/100flags_50users_10fields throughput [540517.282op/s; 548586.465op/s] or [-0.741%; +0.741%] None None None

@dd-octo-sts

dd-octo-sts Bot commented Aug 7, 2026

Copy link
Copy Markdown
Contributor

Artifact Size Benchmark Report

aarch64-alpine-linux-musl
Artifact Baseline Commit Change
/aarch64-alpine-linux-musl/lib/libdatadog_profiling.a 89.19 MB 89.19 MB 0% (0 B) 👌
/aarch64-alpine-linux-musl/lib/libdatadog_profiling.so 8.20 MB 8.20 MB 0% (0 B) 👌
aarch64-unknown-linux-gnu
Artifact Baseline Commit Change
/aarch64-unknown-linux-gnu/lib/libdatadog_profiling.a 100.37 MB 100.37 MB 0% (0 B) 👌
/aarch64-unknown-linux-gnu/lib/libdatadog_profiling.so 11.06 MB 11.06 MB 0% (0 B) 👌
libdatadog-x64-windows
Artifact Baseline Commit Change
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.dll 26.63 MB 26.63 MB 0% (0 B) 👌
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.lib 94.56 KB 94.56 KB 0% (0 B) 👌
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.pdb 191.41 MB 191.42 MB +0% (+8.00 KB) 👌
/libdatadog-x64-windows/debug/static/datadog_profiling_ffi.lib 1001.70 MB 1001.70 MB 0% (0 B) 👌
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.dll 8.71 MB 8.71 MB 0% (0 B) 👌
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.lib 94.56 KB 94.56 KB 0% (0 B) 👌
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.pdb 25.62 MB 25.62 MB 0% (0 B) 👌
/libdatadog-x64-windows/release/static/datadog_profiling_ffi.lib 51.01 MB 51.01 MB 0% (0 B) 👌
libdatadog-x86-windows
Artifact Baseline Commit Change
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.dll 23.22 MB 23.22 MB 0% (0 B) 👌
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.lib 96.04 KB 96.04 KB 0% (0 B) 👌
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.pdb 196.34 MB 196.33 MB -0% (-8.00 KB) 👌
/libdatadog-x86-windows/debug/static/datadog_profiling_ffi.lib 990.83 MB 990.83 MB 0% (0 B) 👌
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.dll 6.73 MB 6.73 MB 0% (0 B) 👌
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.lib 96.04 KB 96.04 KB 0% (0 B) 👌
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.pdb 27.55 MB 27.55 MB --.02% (-8.00 KB) 💪
/libdatadog-x86-windows/release/static/datadog_profiling_ffi.lib 48.56 MB 48.56 MB 0% (0 B) 👌
x86_64-alpine-linux-musl
Artifact Baseline Commit Change
/x86_64-alpine-linux-musl/lib/libdatadog_profiling.a 79.47 MB 79.47 MB 0% (0 B) 👌
/x86_64-alpine-linux-musl/lib/libdatadog_profiling.so 9.13 MB 9.13 MB 0% (0 B) 👌
x86_64-unknown-linux-gnu
Artifact Baseline Commit Change
/x86_64-unknown-linux-gnu/lib/libdatadog_profiling.a 95.12 MB 95.12 MB 0% (0 B) 👌
/x86_64-unknown-linux-gnu/lib/libdatadog_profiling.so 11.14 MB 11.14 MB 0% (0 B) 👌

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

Reviewers

@leoromanovsky leoromanovsky Awaiting requested review from leoromanovsky leoromanovsky is a code owner automatically assigned from DataDog/feature-flagging-and-experimentation-sdk
@typotter typotter Awaiting requested review from typotter typotter is a code owner automatically assigned from DataDog/feature-flagging-and-experimentation-sdk

At least 1 approving review is required to merge this pull request.

Assignees

No one assigned

Labels

crashtracker

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@morrisonlevi