Skip to content

test(ipc): benchmark writes to the DSM shared memory tables - #2737

Open
arjunguhaswe wants to merge 1 commit into
arjun.guha/dsm2-450-php-tracer-complete-the-kafka-integrationfrom
arjun.guha/dsm-shm-table-benches
Open

arjunguhaswe wants to merge 1 commit into
arjun.guha/dsm2-450-php-tracer-complete-the-kafka-integrationfrom
arjun.guha/dsm-shm-table-benches

Conversation

@arjunguhaswe

Copy link
Copy Markdown

What does this PR do?

Stacked on #2729. Adds criterion benchmarks (libdd-ipc/benches/shm_dsm.rs) for the part of a DSM checkpoint or Kafka offset that runs in libdatadog on a PHP request's thread: the write into the sidecar's shared memory tables.

Benchmark What it times
dsm_checkpoint_table/add_existing_pathway A Kafka produce checkpoint for a pathway already in the bucket, as nearly every checkpoint is
dsm_checkpoint_table/add_concurrent_writers/4 The same from 4 writers at once, each with its own mapping of the segment and its own pathway, as PHP worker processes write
dsm_backlog_table/add_produce_offset_partitions/16 A produce offset across 16 partitions, parsing the key:value tags as ddog_dsm_track_backlog does

Each benchmark creates its table as the sidecar does and writes through a handle opened by name, as a worker does, so the check for a replaced table that workers make on every write is timed too.

Motivation

The PHP tracer's phpbench subjects (DataDog/dd-trace-php#4386) time whole checkpoints, of which the table write is under a tenth. A slowdown in the tables would be diluted there, and would only show once dd-trace-php bumps libdatadog. These run in this repo's CI for any PR that touches libdd-ipc, including client stats changes to the shm_table.rs both share.

Additional Notes

  • No new dependencies, and nothing outside the bench target changes.
  • What 4 writers on different pathways share is the bucket header's in_flight counter, which every write updates twice. Locally, a write takes about 10× as long with 4 writers as with one.
  • Local results on an Apple M5 Pro (macOS, arm64), with CI's criterion arguments. They aren't comparable to CI numbers.
Benchmark Time per write
add_existing_pathway 18 ns
add_concurrent_writers/4 180 ns
add_produce_offset_partitions/16 31 ns
  • libdd-ipc keeps its shard weight of 1 (about 30 s) in select_bench_packages.sh: with ipc's two subjects, that's five at CI's 6 s each.

How to test the change?

cargo bench -p libdd-ipc --bench shm_dsm

🤖 Generated with Claude Code

Time the part of a DSM checkpoint or Kafka offset that runs in
libdatadog on a PHP request's thread: a checkpoint for a pathway
already in the bucket, the same from 4 writers at once, and a produce
offset across 16 partitions.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@arjunguhaswe
arjunguhaswe requested review from a team as code owners October 27, 2026 20:17
@chatgpt-codex-connector

chatgpt-codex-connector Bot commented Oct 27, 2026 •

Copy link
Copy Markdown

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review Status Commit Review trigger
📝 Code Review ✅ Completed 2026-10-27T20:21:37.071800Z 02adb4f PR opened
ℹ️ 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" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

@github-actions

Copy link
Copy Markdown
Contributor

📚 Documentation Check Results

⚠️ 1064 documentation warning(s) found

📦 libdd-ipc - 1064 warning(s)


Updated: 2026-10-27 20:20:23 UTC | Commit: 1a8cc80 | missing-docs job results

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 02adb4fa2e

ℹ️ About Codex in GitHub

Codex has been enabled to automatically 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 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

Comment on lines +143 to +144
start.wait();
let started = Instant::now();

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

P1 Badge Start timing before releasing concurrent writers

When the main benchmark thread is delayed after start.wait() returns, the worker threads have already been released and can perform some or even all of their iterations before this timestamp is captured. The measured duration then excludes an arbitrary portion of the workload, producing spuriously low and scheduler-dependent results; use separate ready/start synchronization so the timestamp is recorded before the workers begin.

Useful? React with 👍 / 👎.

@github-actions

Copy link
Copy Markdown
Contributor

🔒 Cargo Deny Results

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

📦 libdd-ipc - 6 error(s)

Show output
info: syncing channel updates for 1.87.0-x86_64-unknown-linux-gnu
info: latest update on 2025-05-15 for version 1.87.0 (17067e9ac 2025-05-09)
info: downloading 6 components
warn: the missing active toolchain `1.87.0-x86_64-unknown-linux-gnu` has been auto-installed
warn: this might cause rustup commands to take longer time to finish than expected
info: you may opt out with `RUSTUP_AUTO_INSTALL=0` or `rustup set auto-install disable`
error[unmaintained]: Bincode is unmaintained
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:24:1
   │
24 │ 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
     └── libdd-ipc v2.0.0

error[vulnerability]: TLS 1.3 handshake messages incorrectly accepted across encryption level boundaries
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:230:1
    │
230 │ rustls 0.23.37 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
    │
    ├ ID: RUSTSEC-2026-0285
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0285
    ├ Rustls accepted TLS 1.3 handshake messages sent at the wrong encryption level
      when they followed a key-changing message in the same record. For example,
      a plaintext `EncryptedExtensions` message packed into the same record as the
      `ServerHello` was accepted.
      
      RFC 8446 section 5.1 requires that handshake messages do not span key changes,
      and that implementations terminate the connection with an "unexpected_message"
      alert if they do.
      
      The handshake transcript is still authenticated, so a network-position attacker
      cannot use this to alter or complete a handshake; the practical effect is that
      a peer could send handshake messages that should be encrypted in plaintext
      without rustls rejecting the connection.
      
      This is functionally the same bug as Go's
      [GO-2026-4340](https://pkg.go.dev/vuln/GO-2026-4340) (CVE-2025-61730).
    ├ Announcement: https://github.com/rustls/rustls/pull/3265
    ├ Solution: Upgrade to >=0.23.45 (try `cargo update -p rustls`)
    ├ rustls v0.23.37
      ├── hyper-rustls v0.27.7
      │   └── libdd-common v8.0.0
      │       ├── libdd-capabilities-impl v7.0.0
      │       │   ├── libdd-shared-runtime v6.0.0
      │       │   │   └── libdd-trace-stats v11.0.0
      │       │   │       └── libdd-ipc v2.0.0
      │       │   ├── libdd-trace-stats v11.0.0 (*)
      │       │   └── libdd-trace-utils v14.0.0
      │       │       ├── libdd-trace-obfuscation v10.0.0
      │       │       │   └── libdd-trace-stats v11.0.0 (*)
      │       │       ├── libdd-trace-stats v11.0.0 (*)
      │       │       └── (dev) libdd-trace-utils v14.0.0 (*)
      │       ├── libdd-ipc v2.0.0 (*)
      │       ├── libdd-shared-runtime v6.0.0 (*)
      │       ├── libdd-trace-obfuscation v10.0.0 (*)
      │       ├── libdd-trace-stats v11.0.0 (*)
      │       └── libdd-trace-utils v14.0.0 (*)
      ├── libdd-common v8.0.0 (*)
      ├── rustls-platform-verifier v0.6.2
      │   └── libdd-common v8.0.0 (*)
      └── tokio-rustls v0.26.0
          └── hyper-rustls v0.27.7 (*)

error[vulnerability]: `Debug` impls for client session values expose TLS secrets
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:230:1
    │
230 │ rustls 0.23.37 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
    │
    ├ ID: RUSTSEC-2026-0346
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0346
    ├ The `Debug` implementations of `Tls12ClientSessionValue` and
      `Tls13ClientSessionValue` were derived, and so included the TLS 1.2 master
      secret or TLS 1.3 resumption PSK in their output.
      
      Custom `ClientSessionStore` implementations that format these values with
      `Debug` (for example, when logging) could disclose these secrets to readers of
      the logs. This conflicts with rustls's
      [key-material redaction policy](https://github.com/rustls/rustls/blob/99f2358cae2954837dbb866faf6727de75489ab9/SECURITY.md#boundary-public-api).
      
      Ordinary connection and built-in session cache `Debug` output is redacted and
      is not affected.
    ├ Announcement: https://github.com/rustls/rustls/pull/3299
    ├ Solution: Upgrade to >=0.23.46 (try `cargo update -p rustls`)
    ├ rustls v0.23.37
      ├── hyper-rustls v0.27.7
      │   └── libdd-common v8.0.0
      │       ├── libdd-capabilities-impl v7.0.0
      │       │   ├── libdd-shared-runtime v6.0.0
      │       │   │   └── libdd-trace-stats v11.0.0
      │       │   │       └── libdd-ipc v2.0.0
      │       │   ├── libdd-trace-stats v11.0.0 (*)
      │       │   └── libdd-trace-utils v14.0.0
      │       │       ├── libdd-trace-obfuscation v10.0.0
      │       │       │   └── libdd-trace-stats v11.0.0 (*)
      │       │       ├── libdd-trace-stats v11.0.0 (*)
      │       │       └── (dev) libdd-trace-utils v14.0.0 (*)
      │       ├── libdd-ipc v2.0.0 (*)
      │       ├── libdd-shared-runtime v6.0.0 (*)
      │       ├── libdd-trace-obfuscation v10.0.0 (*)
      │       ├── libdd-trace-stats v11.0.0 (*)
      │       └── libdd-trace-utils v14.0.0 (*)
      ├── libdd-common v8.0.0 (*)
      ├── rustls-platform-verifier v0.6.2
      │   └── libdd-common v8.0.0 (*)
      └── tokio-rustls v0.26.0
          └── hyper-rustls v0.27.7 (*)

error[vulnerability]: Brotli certificate decompression can allocate up to 1 GiB before authentication
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:230:1
    │
230 │ rustls 0.23.37 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
    │
    ├ ID: RUSTSEC-2026-0348
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0348
    ├ The built-in Brotli certificate decompressor (enabled by the non-default
      `brotli` crate feature) bounded the size of the decompressed output, but
      accepted a peer-selected history window. Brotli's large-window extension was
      enabled, so a five-byte header could cause an allocation of 1 GiB. A peer can
      abort a process whose allocator cannot satisfy that request.
      
      No trusted certificate is required by the attacker. Affected configurations are:
      
      - clients that enable the `brotli` feature and connect to a malicious server, and
      - servers that enable the `brotli` feature and request client certificates.
      
      Applications that do not enable the `brotli` feature are not affected.
    ├ Announcement: https://github.com/rustls/rustls/pull/3297
    ├ Solution: Upgrade to >=0.23.46 (try `cargo update -p rustls`)
    ├ rustls v0.23.37
      ├── hyper-rustls v0.27.7
      │   └── libdd-common v8.0.0
      │       ├── libdd-capabilities-impl v7.0.0
      │       │   ├── libdd-shared-runtime v6.0.0
      │       │   │   └── libdd-trace-stats v11.0.0
      │       │   │       └── libdd-ipc v2.0.0
      │       │   ├── libdd-trace-stats v11.0.0 (*)
      │       │   └── libdd-trace-utils v14.0.0
      │       │       ├── libdd-trace-obfuscation v10.0.0
      │       │       │   └── libdd-trace-stats v11.0.0 (*)
      │       │       ├── libdd-trace-stats v11.0.0 (*)
      │       │       └── (dev) libdd-trace-utils v14.0.0 (*)
      │       ├── libdd-ipc v2.0.0 (*)
      │       ├── libdd-shared-runtime v6.0.0 (*)
      │       ├── libdd-trace-obfuscation v10.0.0 (*)
      │       ├── libdd-trace-stats v11.0.0 (*)
      │       └── libdd-trace-utils v14.0.0 (*)
      ├── libdd-common v8.0.0 (*)
      ├── rustls-platform-verifier v0.6.2
      │   └── libdd-common v8.0.0 (*)
      └── tokio-rustls v0.26.0
          └── hyper-rustls v0.27.7 (*)

error[vulnerability]: Unauthenticated ServerHello can downgrade later connections to classical key exchange
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:230:1
    │
230 │ rustls 0.23.37 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
    │
    ├ ID: RUSTSEC-2026-0349
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0349
    ├ The client recorded the server-selected key exchange group for each server
      name when processing the ServerHello, before the server was authenticated.
      This record is used to predict which key share to send in future ClientHellos
      to that server name.
      
      A network attacker can answer one connection attempt with a ServerHello
      selecting X25519, and then close the connection. Later ClientHellos for that
      name carry only an X25519 key share, while `supported_groups` still lists
      X25519MLKEM768 first. If the genuine server accepts that share rather than
      sending a HelloRetryRequest for its preferred hybrid group, the handshake
      completes with classical-only key exchange and no error. This persists for as
      long as the entry stays in the client's session store.
      
      The impact is loss of post-quantum confidentiality for affected connections
      ("harvest now, decrypt later"). There is no key compromise and no
      authentication bypass.
      
      The following are not affected:
      
      - connections to servers which send a HelloRetryRequest for their preferred group,
      - clients with resumption disabled (as nothing is stored), and
      - other server names.
      
      This behaviour is discussed in
      [draft-ietf-tls-key-share-prediction](https://www.ietf.org/archive/id/draft-ietf-tls-key-share-prediction-01.html#name-security-considerations),
      so the practical impact depends largely on server policy.
    ├ Announcement: https://github.com/rustls/rustls/pull/3355
    ├ Solution: Upgrade to >=0.23.46 (try `cargo update -p rustls`)
    ├ rustls v0.23.37
      ├── hyper-rustls v0.27.7
      │   └── libdd-common v8.0.0
      │       ├── libdd-capabilities-impl v7.0.0
      │       │   ├── libdd-shared-runtime v6.0.0
      │       │   │   └── libdd-trace-stats v11.0.0
      │       │   │       └── libdd-ipc v2.0.0
      │       │   ├── libdd-trace-stats v11.0.0 (*)
      │       │   └── libdd-trace-utils v14.0.0
      │       │       ├── libdd-trace-obfuscation v10.0.0
      │       │       │   └── libdd-trace-stats v11.0.0 (*)
      │       │       ├── libdd-trace-stats v11.0.0 (*)
      │       │       └── (dev) libdd-trace-utils v14.0.0 (*)
      │       ├── libdd-ipc v2.0.0 (*)
      │       ├── libdd-shared-runtime v6.0.0 (*)
      │       ├── libdd-trace-obfuscation v10.0.0 (*)
      │       ├── libdd-trace-stats v11.0.0 (*)
      │       └── libdd-trace-utils v14.0.0 (*)
      ├── libdd-common v8.0.0 (*)
      ├── rustls-platform-verifier v0.6.2
      │   └── libdd-common v8.0.0 (*)
      └── tokio-rustls v0.26.0
          └── hyper-rustls v0.27.7 (*)

error[unsound]: `AsyncFd::new` and related constructors violate I/O safety
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:280:1
    │
280 │ tokio 1.49.0 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ unsound advisory detected
    │
    ├ ID: RUSTSEC-2026-0386
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0386
    ├ `tokio::io::unix::AsyncFd` provides safe constructors (`new`, `with_interest`, `try_new`, and `try_with_interest`) that accept any `T: AsRawFd` rather than requiring proof of ownership or validity of the file descriptor. Because `RawFd` implements `AsRawFd`, safe code can construct an `AsyncFd` from an arbitrary or closed file descriptor, or close/replace the underlying file descriptor while the `AsyncFd` is still alive.
      
      This violates I/O safety in two ways:
      
      1. `AsyncFd<T>` implements `AsFd` for all `T: AsRawFd` by calling `BorrowedFd::borrow_raw(self.as_raw_fd())`, allowing safe code to obtain an arbitrary `BorrowedFd<'_>` without owning the file descriptor.
      2. Tokio's I/O driver stores a pointer to an internal allocation in the `epoll`/`kqueue` user data for registered file descriptors. If the underlying file descriptor is duplicated and then closed while an `AsyncFd` is alive, and the OS reuses that file descriptor number for a another IO resource on the same runtime, dropping the first `AsyncFd` deregisters the reused file descriptor number and frees the first while the original file description remains registered in `epoll`, leading to a use-after-free when a readiness event fires.
      
      Starting in Tokio 1.51.6, 1.53.3, and 1.54.0, `AsyncFd::new`, `AsyncFd::with_interest`, `AsyncFd::try_new`, and `AsyncFd::try_with_interest` are deprecated in favor of the `unsafe` constructors `AsyncFd::register` and `AsyncFd::register_with_interest`. Callers must ensure that the file descriptor remains valid, open, and unchanged for the lifetime of the `AsyncFd`.
    ├ Announcement: https://github.com/tokio-rs/tokio/pull/8587
    ├ Solution: Upgrade to >=1.51.6, <1.52.0 OR >=1.53.3 (try `cargo update -p tokio`)
    ├ tokio v1.49.0
      ├── h2 v0.4.19
      │   └── hyper v1.11.1
      │       ├── httpmock v0.8.0-alpha.1
      │       │   ├── (dev) libdd-trace-stats v11.0.0
      │       │   │   └── libdd-ipc v2.0.0
      │       │   └── libdd-trace-utils v14.0.0
      │       │       ├── libdd-trace-obfuscation v10.0.0
      │       │       │   └── libdd-trace-stats v11.0.0 (*)
      │       │       ├── libdd-trace-stats v11.0.0 (*)
      │       │       └── (dev) libdd-trace-utils v14.0.0 (*)
      │       ├── hyper-rustls v0.27.7
      │       │   └── libdd-common v8.0.0
      │       │       ├── libdd-capabilities-impl v7.0.0
      │       │       │   ├── libdd-shared-runtime v6.0.0
      │       │       │   │   └── libdd-trace-stats v11.0.0 (*)
      │       │       │   ├── libdd-trace-stats v11.0.0 (*)
      │       │       │   └── libdd-trace-utils v14.0.0 (*)
      │       │       ├── libdd-ipc v2.0.0 (*)
      │       │       ├── libdd-shared-runtime v6.0.0 (*)
      │       │       ├── libdd-trace-obfuscation v10.0.0 (*)
      │       │       ├── libdd-trace-stats v11.0.0 (*)
      │       │       └── libdd-trace-utils v14.0.0 (*)
      │       ├── hyper-util v0.1.17
      │       │   ├── httpmock v0.8.0-alpha.1 (*)
      │       │   ├── hyper-rustls v0.27.7 (*)
      │       │   └── libdd-common v8.0.0 (*)
      │       ├── libdd-common v8.0.0 (*)
      │       └── libdd-trace-utils v14.0.0 (*)
      ├── httpmock v0.8.0-alpha.1 (*)
      ├── hyper v1.11.1 (*)
      ├── hyper-rustls v0.27.7 (*)
      ├── hyper-util v0.1.17 (*)
      ├── (dev) libdd-capabilities-impl v7.0.0 (*)
      ├── (dev) libdd-common v8.0.0 (*)
      ├── (dev) libdd-ipc v2.0.0 (*)
      ├── libdd-shared-runtime v6.0.0 (*)
      ├── (dev) libdd-trace-protobuf v5.1.0
      │   ├── libdd-ipc v2.0.0 (*)
      │   ├── libdd-trace-normalization v4.2.0
      │   │   └── libdd-trace-utils v14.0.0 (*)
      │   ├── libdd-trace-obfuscation v10.0.0 (*)
      │   ├── libdd-trace-stats v11.0.0 (*)
      │   └── libdd-trace-utils v14.0.0 (*)
      ├── (dev) libdd-trace-stats v11.0.0 (*)
      ├── libdd-trace-utils v14.0.0 (*)
      ├── tokio-rustls v0.26.0
      │   └── hyper-rustls v0.27.7 (*)
      └── tokio-util v0.7.12
          ├── h2 v0.4.19 (*)
          └── libdd-shared-runtime v6.0.0 (*)

advisories FAILED, bans ok, sources ok

Updated: 2026-10-27 20:22:03 UTC | Commit: 1a8cc80 | dependency-check job results

@datadog-prod-us1-6

datadog-prod-us1-6 Bot commented Oct 27, 2026 •

Copy link
Copy Markdown

Pipelines  Tests

✨ Unblock PR with BitsAI

❌ Errors

Your PR has failed checks. Please review the issues below and take necessary action before merging.

🚦 3 Pipeline jobs failed

DataDog/apm-reliability/libdatadog | benchmarks 2/3 — 🔧 Needs a code fix, caused by this PR

View more details · View in GitLab

DataDog/apm-reliability/libdatadog | benchmarks 3/3 — 🔧 Needs a code fix, caused by this PR

View more details · View in GitLab

DataDog/apm-reliability/libdatadog | benchmarks 1/3

View more details · View in GitLab

ℹ️ Info

No other issues found (see more)

🧪 All tests passed
❄️ No new flaky tests detected

🎯 Code Coverage (details)
• Patch Coverage: 100.00%
• Overall Coverage: 79.28% (+0.02%)

Useful? React with 👍 / 👎

This comment will be updated automatically if new data arrives.
🔗 Commit SHA: 02adb4f | Docs | View more details | Give us feedback!

@dd-octo-sts

dd-octo-sts Bot commented Oct 27, 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.so 9.08 MB 9.21 MB +1.37% (+128.23 KB) ⚠️
/aarch64-alpine-linux-musl/lib/libdatadog_profiling.a 96.56 MB 95.88 MB --.69% (-691.75 KB) 💪
aarch64-unknown-linux-gnu
Artifact Baseline Commit Change
/aarch64-unknown-linux-gnu/lib/libdatadog_profiling.a 108.05 MB 107.00 MB --.97% (-1.05 MB) 💪
/aarch64-unknown-linux-gnu/lib/libdatadog_profiling.so 12.29 MB 12.31 MB +.17% (+21.73 KB) 🔍
libdatadog-x64-windows
Artifact Baseline Commit Change
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.dll 29.24 MB 29.56 MB +1.07% (+322.50 KB) ⚠️
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.lib 99.56 KB 99.02 KB --.54% (-556 B) 💪
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.pdb 193.18 MB 194.24 MB +.54% (+1.06 MB) 🔍
/libdatadog-x64-windows/debug/static/datadog_profiling_ffi.lib 822.80 MB 819.74 MB --.37% (-3.06 MB) 💪
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.dll 9.81 MB 9.69 MB --1.18% (-119.50 KB) 💪
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.lib 99.56 KB 99.02 KB --.54% (-556 B) 💪
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.pdb 27.60 MB 27.66 MB +.19% (+56.00 KB) 🔍
/libdatadog-x64-windows/release/static/datadog_profiling_ffi.lib 55.88 MB 55.67 MB --.37% (-214.62 KB) 💪
libdatadog-x86-windows
Artifact Baseline Commit Change
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.dll 25.68 MB 26.06 MB +1.49% (+394.00 KB) ⚠️
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.lib 101.12 KB 100.56 KB --.55% (-572 B) 💪
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.pdb 198.82 MB 199.83 MB +.50% (+1.00 MB) 🔍
/libdatadog-x86-windows/debug/static/datadog_profiling_ffi.lib 809.61 MB 806.36 MB --.40% (-3.24 MB) 💪
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.dll 7.60 MB 7.48 MB --1.52% (-118.50 KB) 💪
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.lib 101.12 KB 100.56 KB --.55% (-572 B) 💪
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.pdb 29.73 MB 29.71 MB --.07% (-24.00 KB) 💪
/libdatadog-x86-windows/release/static/datadog_profiling_ffi.lib 52.81 MB 52.54 MB --.51% (-279.85 KB) 💪
x86_64-alpine-linux-musl
Artifact Baseline Commit Change
/x86_64-alpine-linux-musl/lib/libdatadog_profiling.a 86.56 MB 86.42 MB --.16% (-148.32 KB) 💪
/x86_64-alpine-linux-musl/lib/libdatadog_profiling.so 10.12 MB 9.99 MB --1.27% (-131.74 KB) 💪
x86_64-unknown-linux-gnu
Artifact Baseline Commit Change
/x86_64-unknown-linux-gnu/lib/libdatadog_profiling.a 102.39 MB 101.97 MB --.40% (-421.86 KB) 💪
/x86_64-unknown-linux-gnu/lib/libdatadog_profiling.so 12.37 MB 12.22 MB --1.20% (-152.96 KB) 💪

This branch has not been deployed

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant