[Perf] Windows/x64: 2 Regressions on 8/24/2026 9:00:53 AM +00:00

[performanceautofiler]

Run Information

Name	Value
Architecture	x64
OS	Windows 10.0.22631
Queue	ViperWindows
Baseline	64a29867c5c5c8e0babc9e31313cf3b6e50f0193
Compare	c545c4e3f9e2ebc10c6b3e2626187e18569adcf2
Diff	Diff
Configs	CompilationMode:tiered, RunKind:bepuphysics

Regressions in DemoBenchmarks.TwoBodyConstraintBenchmarks

Benchmark	Baseline	Test	Test/Base	Test Quality	Edge Detector	Baseline IR	Compare IR	IR Ratio
Contact4Nonconvex - Duration of single invocation 📝 - Benchmark Source ADX - Test Multi Config Graph	485.04 μs	611.83 μs	1.26	0.00	True
SwivelHinge - Duration of single invocation 📝 - Benchmark Source ADX - Test Multi Config Graph	118.44 μs	133.08 μs	1.12	0.00	True

Test Report

Repro

General Docs link: https://github.com/dotnet/performance/blob/main/docs/benchmarking-workflow-dotnet-runtime.md

git clone https://github.com/dotnet/performance.git
py .\performance\scripts\benchmarks_ci.py -f net8.0 --filter 'DemoBenchmarks.TwoBodyConstraintBenchmarks*'

Details

DemoBenchmarks.TwoBodyConstraintBenchmarks.Contact4Nonconvex

ETL Files

Histogram

JIT Disasms

DemoBenchmarks.TwoBodyConstraintBenchmarks.SwivelHinge

ETL Files

Histogram

JIT Disasms

Docs

Profiling workflow for dotnet/runtime repository
Benchmarking workflow for dotnet/runtime repository

[LoopedBard3]

🔍 Automated Triage Analysis

Summary: One confirmed regression in DemoBenchmarks.TwoBodyConstraintBenchmarks.Contact4Nonconvex (+26.1%, 485.0 → 611.8 µs; z=4.47, discrete step change against a stable 300-run history), while SwivelHinge (+12.4%) is measurement noise (z=1.43, below the 14.3% adaptive threshold for a high-variance test). Regression confidence 4/5 for Contact4Nonconvex, but no commit attribution is possible: the baseline/compare SHAs are dotnet/sdk 11.0 (VMR-composed) commits that are not resolvable in the public do Bisection skipped — autofile run configuration is not supported by the bisection harness.

Finding Confidence: 3/5 (analysis accuracy)
Regression Confidence: 4/5 (likelihood of true regression)

🤖 Proposed Next Actions: Uncertain — flag for re-triage — 1 done, 1 dry-run (rule R5_look_again — see Full Analysis for the table). · 🦆 Re-analysis: ⚠️ disputes (overconfident, weak-bisection-evidence)

📊 Full Analysis (click to expand)

Summary: One confirmed regression in DemoBenchmarks.TwoBodyConstraintBenchmarks.Contact4Nonconvex (+26.1%, 485.0 → 611.8 µs; z=4.47, discrete step change against a stable 300-run history), while SwivelHinge (+12.4%) is measurement noise (z=1.43, below the 14.3% adaptive threshold for a high-variance test). Regression confidence 4/5 for Contact4Nonconvex, but no commit attribution is possible: the baseline/compare SHAs are dotnet/sdk 11.0 (VMR-composed) commits that are not resolvable in the public dotnet/sdk repository, so the culprit runtime change could not be isolated. Finding confidence 3/5 — statistics are strong, but the commit range is inaccessible and the result is unverified.

Issue Overview

• Issue: #78333 - [Perf] Windows/x64: 2 Regressions on 8/24/2026 9:00:53 AM +00:00
• Date: 2026-08-24 | Queue: ViperWindows (Windows.11.Amd64.Viper.Perf) | OS/Arch: Windows 10.0.22631 / x64
• Runtime stack: Desktop + CoreCLR (tiered compilation, RunKind=bepuphysics)
• Commits: 64a29867 → c545c4e3 (dotnet/sdk 11.0; range not resolvable — see Open Questions)
• Labels: untriaged, perf-regression, os-windows, arch-x64, runtime-coreclr, kind-bepuphysics, branch-11.0, compilationmode-tiered, runkind-bepuphysics
• Description: Autofiler reported 2 regressions in DemoBenchmarks.TwoBodyConstraintBenchmarks (a BepuPhysics2 real-world, SIMD-heavy constraint-solver benchmark).
• Historical Data: Available (300 prior runs per test; sufficient for high-confidence statistics)

Test Analysis

Test Name	Baseline	Compare	Δ%	μ	σ	n	z	Thresh%	Noise?	Assessment
Contact4Nonconvex	485.04 µs	611.83 µs	+26.14%	496.44 µs	25.81 µs	300	4.47	10.4%	N	Step change, stable history (CV=5.2%)
SwivelHinge	118.44 µs	133.08 µs	+12.36%	120.71 µs	8.65 µs	300	1.43	14.34%	Y	Within variance; high CV=7.17%, frequent spikes (max≈176.7 µs)

Legend: μ=mean, σ=stddev, n=runs, z=z-score, Thresh%=adaptive threshold

Finding Confidence: 3/5 - Strong historical data (300 runs, low-to-moderate variance) supports the statistical classification, but the dotnet/sdk 11.0 commit range is inaccessible (VMR-composed / not public), preventing attribution, and the regression was not verified via rerun/bisection.

Candidate Stack Relevance

The baseline/compare commits are dotnet/sdk 11.0 SHAs. Both GetCommitRangeSummary and GetCommitRangeHashes returned Comparison not found, and each SHA individually returned No commit found in the public dotnet/sdk repository. The range is therefore composed from the VMR (dotnet/dotnet) / internal 11.0 bits and could not be enumerated. No per-commit stack-relevance table can be produced.

Commit	Touched Paths (summary)	Relevance	Notes
(range unavailable)	—	Unknown	dotnet/sdk 11.0 SHAs not resolvable in public repo; runtime bits composed via VMR.

Confirmed Regressions

DemoBenchmarks.TwoBodyConstraintBenchmarks.Contact4Nonconvex (+26.1%)

• Delta: 485.04 µs → 611.83 µs (+26.14%)
• Historical Context: μ=496.44 µs (σ=25.81 µs, n=300); z-score=4.47; adaptive threshold=10.4%; CV=5.2%
• Assessment: Step change. The compare value (611.8 µs) is ~4.5σ above the historical mean and a clear outlier above the surrounding recent range (~483k–552k ns), consistent with a discrete regression rather than drift or noise.
• Finding Confidence: 3/5 - Robust statistics (300 runs, stable series), but commit range inaccessible and result unverified.
• Regression Confidence: 4/5 - Very strong signal (z=4.47, +26%, step change against a stable history). Not 5/5 because there is no commit attribution and no rerun/bisection verification.
• Likely Cause: None identified. The dotnet/sdk 11.0 commit range could not be resolved, so no candidate runtime commit can be named.
  • Affected Areas: Most plausibly JIT codegen / SIMD vectorization — Contact4Nonconvex is a Vector<float>-intensive constraint solve (see benchmark source), so runtime changes to vectorized codegen, inlining, or register allocation are the typical drivers for a step change of this magnitude. This is a hypothesis based on the workload, not a confirmed attribution.
  • Stack Relevance: Unknown (commit range unavailable)
  • Rationale: The benchmark (source) is a wide-SIMD two-body contact constraint prestep/solve built entirely on Vector<float> / Vector3Wide operations, making it highly sensitive to JIT vectorization and codegen quality. A +26% step change points to a runtime/JIT change composed into the SDK build, but the specific commit cannot be isolated because the SHA range is not enumerable.
  • Candidates Considered: None — commit range enumeration failed (Comparison not found).
• Verification Status: Not verified. Bisection/rerun via RunWithBuildAtHash was not attempted because the build SHAs belong to dotnet/sdk 11.0 (VMR-composed) and are not resolvable to a runtime commit range.

DemoBenchmarks.TwoBodyConstraintBenchmarks.SwivelHinge (+12.4%) — Noise

• Delta: 118.44 µs → 133.08 µs (+12.36%)
• Historical Context: μ=120.71 µs (σ=8.65 µs, n=300); z-score=1.43; adaptive threshold=14.34%; CV=7.17%
• Assessment: Noise. Δ% is below the (elevated) adaptive threshold and z<2. This test has high natural variability with frequent large spikes (max≈176.7 µs); the compare value sits well within the historical range. Note a mild upward drift (recent-before mean ≈122.2 µs vs early-before mean ≈118.5 µs, ~3%) worth monitoring but not actionable now.

Open Questions

• Historical Data: Sufficient — 300 runs per test; no data gap. SwivelHinge exhibits high variance (CV=7.17%), reducing its regression sensitivity.
• Confidence Limitations: Commit range inaccessible — baseline/compare are dotnet/sdk 11.0 SHAs not present in the public dotnet/sdk repo; attribution to a runtime commit is impossible from this data alone.
• Verification Needed: Isolated rerun of Contact4Nonconvex on baseline vs compare to confirm reproducibility; if reproduced, map the SDK 11.0 range to the underlying dotnet/runtime commit window and bisect there.
• Bisection Status: Not performed (build SHAs not resolvable to a runtime commit range).

Recommended Actions

1. Resolve the runtime commit window - Map dotnet/sdk 11.0 64a29867…c545c4e3 to the corresponding dotnet/runtime (VMR) commit range so the change set can be enumerated and bisected.
2. Verify reproducibility - Rerun DemoBenchmarks.TwoBodyConstraintBenchmarks.Contact4Nonconvex on the baseline and compare runtime bits to confirm the +26% step change is stable and not a one-off.
3. Bisect once range is known - After mapping, use RunWithBuildAtHash / bisection over the runtime range, focusing on JIT/SIMD codegen changes, to isolate the culprit commit.
4. Monitor SwivelHinge - Track the mild upward drift (~3%); no action now (classified noise).

🤖 Proposed Next Actions

Rule: R5_look_again — Uncertain — flag for re-triage.

Finding confidence 3/5 is below the required 4/5. Revisit once more historical data is available.

#	Action	Status	Details
1	Add label	✅ Done	Look Again
2	Remove label	⏭️ Skipped (dry-run)	untriaged

🦆 Re-analysis (advisory)

⚠️ Disputes the analysis — advisory only, not applied

Flags: overconfident, weak-bisection-evidence

Rationale: The actionable finding (Contact4Nonconvex) carries a 4/5 regression confidence, yet its bisection was skipped with no culprit and stackRelevance=Unknown, so there is no convergence, z-score, or sustained-after evidence to justify a high change confidence. The SwivelHinge noise call (findingConf=4, noise=True, changeConf=1) is self-consistent and fine, but the elevated change confidence on the unsupported regression should be lowered.

Suggested confidence: Change Confidence → 2/5 (advisory — not applied)

This critique is advisory in the current configuration and did not change the confidences, culprit, or proposed actions above.

---

Generated by PerfTriageAgent on 2026-08-24 09:05 UTC