Repository navigation
Conversation
Add J14: on per-request / per-message paths, flag work whose only consumer is an optional product (DSM, DBM, DJM, AppSec, ...) that isn't behind that product's enabled check. Arguments built for a no-op receiver are still paid for, and "no-op" must be verified in the implementation that actually runs (DSM's trackBacklog still allocates and queues when DSM is off). Name each product's existing gate and whether it is static or dynamic. Also correct two statements that steered reviews away from this: the "no-op sink, stay silent" rule now clears only the call, not its arguments; and DSM is removed from the large-denominator domains (the Spark example there is DJM; DSM runs on per-message paths). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Keep the trigger, the no-op-receiver and verify-the-running-impl points, the per-product gates and the don't-flag cases; drop the long measurement narrative and code snippets. Add the shared-call case: gate only the product's part of a propagation inject. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 4a4ca07040
ℹ️ 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".
There was a problem hiding this comment.
More details
The added guidance matches existing product enablement checks and correctly distinguishes no-op calls from the cost of eagerly building their arguments. The completed static review produced no reportable findings.
🤖 Bits Code Review · Commit 4a4ca07
🟢 Java Benchmark SLOs — All performance SLOs passed
PR vs. master results
Commit: Load and DaCapo benchmarks can be triggered manually in the GitLab pipeline. Results will appear in the Benchmarking Platform UI after completion. |
…check The blanket exemption for a product's own components covered entry points such as DefaultDataStreamsMonitoring.trackBacklog, which app threads call even when DSM is off. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
What Does This Do
Adds J14 — Work done for an optional product that's off to the
/perf-reviewrubric: on a per-request / per-message path, flag work done only for an optional product (DSM, DBM, DJM, AppSec, …) that isn't behind that product's enabled check. It names each product's existing check (and whether it's static or dynamic), and notes that a no-op receiver doesn't make the arguments free, and that the no-op has to be verified in the running implementation.It also fixes two statements that pointed reviews the other way:
Motivation
The same miss shipped in five messaging paths (#13075, #13079–#13082). For the Kafka consumer, guarding it saved 548 B per record (−13.7% allocation) and gained 6.6% throughput.
Additional Notes
Back-tested by hand on the pre-fix code: it flags all five fixed sites and stays silent on the code that was already correct (gRPC client, SNS 2.0, Mongo DBM, JDBC's DBM checks, DJM's checks in core, the gRPC server's single precomputed-tags context).
Numbered J14 because #13005 claims J13. Merges cleanly with the open perf-review PRs.
Jira ticket: APMLP-2124
🤖 Generated with Claude Code