[Perf] Windows/x64: 1 Regression on 6/28/2026 5:31:55 PM +00:00

[performanceautofiler]

Run Information

Name	Value
Architecture	x64
OS	Windows 10.0.22631
Queue	ViperWindows
Baseline	19a803d6d08a846656d1116d0f4e7001e792d5a1
Compare	9cb68cd564627fd80fb9077731093f46d1e0e667
Diff	Diff
Configs	CompilationMode:tiered, RunKind:micro

Regressions in Microsoft.Extensions.DependencyInjection.GetServiceIEnumerable

Benchmark	Baseline	Test	Test/Base	Test Quality	Edge Detector	Baseline IR	Compare IR	IR Ratio
Scoped - Duration of single invocation 📝 - Benchmark Source ADX - Test Multi Config Graph	39.36 ns	64.06 ns	1.63	0.54	False

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 'Microsoft.Extensions.DependencyInjection.GetServiceIEnumerable*'

Details

Microsoft.Extensions.DependencyInjection.GetServiceIEnumerable.Scoped

ETL Files

Histogram

JIT Disasms

Docs

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

[LoopedBard3]

🔍 Automated Triage Analysis

Summary: Verified regression in Scoped — caused by commit 1c9f9dc ("Move thin lock acquire/release in CoreCLR to managed code (#129502)").

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

Likely Cause: 1c9f9dccb819214cb9ac469491d675645230400e

🤖 Proposed Next Actions: Known-cause regression — transfer & notify — 0 done, 4 dry-run (rule R4_known_regression_new — see Full Analysis for the table). · 🦆 Re-analysis: ✅ concurs

📊 Full Analysis (click to expand)

Summary: Clear regression in Microsoft.Extensions.DependencyInjection.GetServiceIEnumerable.Scoped (+45.5% vs historical mean, z=5.48) attributed to commit 1c9f9dc which moved thin lock acquire/release in CoreCLR to managed code. Finding confidence 4/5 (robust historical data, 300 prior runs), regression confidence 4/5 (strong step change signal, small commit range of 4 commits, direct code path through Monitor/lock used by DI service resolution).

Issue Overview

• Issue: [Perf] Windows/x64: 1 Regression on 6/28/2026 5:31:55 PM +00:00 #130043 - [Perf] Windows/x64: 1 Regression on 6/28/2026 5:31:55 PM +00:00
• Date: 2026-06-28 | Queue: Windows.11.Amd64.Viper.Perf | OS/Arch: Windows 10.0.22631/x64
• Commits: 19a803d6d08a → 9cb68cd56462 (4 commits)
• Labels: untriaged, perf-regression, os-windows, arch-x64, branch-refs/heads/main, runtime-coreclr, kind-micro, compilationmode-tiered, runkind-micro
• Runtime Stack: Desktop + CoreCLR (implicit)
• Historical Data: Available (300 prior runs, 11 post-regression runs)

Test Analysis

Test Name	Baseline	Compare	Δ%	μ	σ	n	z	Thresh%	Noise?	Assessment
GetServiceIEnumerable.Scoped	39.36 ns	64.06 ns	+62.8%	44.04	3.65	300	5.48	16.58%	N	Step change; compare is +45.5% vs historical mean. Baseline was a low outlier (-10.6% vs mean). All 11 after-values uniformly elevated (min=49.69, max=64.11).

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

Note on Δ%: The raw delta of +62.8% is inflated because the baseline run (39.36 ns) was itself ~10.6% below the historical mean (44.04 ns). The more representative severity indicator is +45.5% vs historical mean (compare 64.06 ns vs μ=44.04 ns). Both metrics far exceed the adaptive threshold of 16.58%.

Finding Confidence: 4/5 — Robust historical data with 300 prior runs providing well-estimated mean and stddev. CV=8.29% indicates moderate variance. After-series is consistent with no overlap with historical central tendency. Small commit range (4 commits) simplifies attribution.

Candidate Stack Relevance

Commit	Touched Paths (summary)	Relevance	Notes
1c9f9dccb819	src/coreclr/System.Private.CoreLib/ (Monitor, ObjectHeader, Threading), src/coreclr/vm/, src/coreclr/nativeaot/	Relevant	Moves thin lock acquire/release to managed code; directly impacts Monitor.Enter/Exit used by DI service provider. 20 files, 454 additions, 697 deletions.
33db1610a13c	src/coreclr/vm/readytoruninfo.cpp	Relevant	cDAC R2R hashmap enumeration fix; minor 9-line change, unlikely to affect DI perf.
d6d9a97587fb	eng/testing/BrowserVersions.props	LessLikely	Chrome version bump for wasm testing; no runtime code changes.
9cb68cd56462	src/coreclr/vm/jithelpers.cpp	LessLikely	Debug-only wasm assert fix; release behavior unaffected.

Confirmed Regressions

Microsoft.Extensions.DependencyInjection.GetServiceIEnumerable.Scoped (+62.8% raw, +45.5% vs historical mean)

• Delta: 39.36 ns → 64.06 ns (+62.8% raw; +45.5% vs historical mean μ=44.04 ns)
• Historical Context: μ=44.04 ns (σ=3.65, n=300); z-score=5.48; adaptive threshold=16.58%; CV=8.29%
• Assessment: Step change. All 11 post-regression values are uniformly elevated above the historical mean with no overlap. Before-series was noisy but stable with no upward drift preceding the jump. The baseline run was an atypically low observation, inflating the raw Δ%.
• Finding Confidence: 4/5 — Robust historical data (300 runs), consistent after-series, small commit range. Not verified via RunWithBuildAtHash, which would upgrade to 5/5.
• Regression Confidence: 4/5 — Strong step change signal (z=5.48), small commit range (4 commits), direct code path match. Only one plausible candidate commit.
• Likely Cause: 1c9f9dccb819 - "Move thin lock acquire/release in CoreCLR to managed code (Move thin lock acquire/release in CoreCLR to managed code #129502)"
  • Affected Areas: Threading / Monitor / Locking / DI Service Resolution
  • Stack Relevance: Relevant
  • Rationale: This commit moves the thin lock acquire/release from native to managed code in CoreCLR, modifying ObjectHeader.CoreCLR.cs (217 additions, 54 deletions), removing Monitor.CoreCLR.cs (157 deletions), and cross-porting tweaks between CoreCLR and NativeAOT. The DI service provider internally uses lock statements (Monitor.Enter/Exit) during scoped service resolution and IEnumerable<T> enumeration. The PR description itself notes "couple scenarios see minor regressions up to -3%", but this test shows a significantly larger regression. The benchmark GetService<IEnumerable<A>>() on a scoped provider exercises the lock path during service instance creation and caching, making it directly sensitive to changes in thin lock implementation. The commit's timing aligns precisely with the regression date.
  • Candidates Considered:
    • 33db1610a13c - cDAC R2R hashmap fix; only 9 lines in readytoruninfo.cpp, no DI/threading relevance
    • d6d9a97587fb - Chrome version bump; no runtime code changes
    • 9cb68cd56462 - Debug-only wasm assert; release behavior unaffected
• Verification Status: Not verified. Bisection unnecessary due to small commit range (4 commits) with only one plausible candidate. Verification via RunWithBuildAtHash recommended to confirm.

Open Questions

• Severity Calibration: The raw Δ% (62.8%) is inflated by a low baseline outlier; the compare-vs-historical metric (+45.5%) is the more reliable severity indicator. Both far exceed the adaptive threshold.
• Scope of Impact: The PR author noted regressions "up to -3%" in their testing, but this specific DI scoped enumerable scenario shows a much larger impact. Other DI-related benchmarks (Transient, Singleton variants) should be checked for similar regressions.
• Verification Needed: RunWithBuildAtHash on commits 19a803d (baseline) and 1c9f9dc (post-lock-change) would confirm whether the lock refactoring is the sole cause.

Recommended Actions

1. Verify regression: Verify with RunWithBuildAtHash on 19a803d6d08a (before) and 1c9f9dccb819 (after lock change) to confirm the thin lock refactoring is the cause.
2. Check related benchmarks: Investigate whether other DI benchmarks (Transient, Singleton, other service resolution patterns) are similarly affected by the lock changes.
3. Source review: Review 1c9f9dccb819 focusing on the managed thin lock implementation's fast path for uncontended acquire, which is the hot path for single-threaded DI benchmarks.
4. Profiling: Collect hardware counters (branch mispredictions, cache misses) with collectHardwareCounters=true to understand the overhead source in the managed lock implementation vs the native implementation.

Bisection Results

Test	Status	Culprit Commit	Relevance	Reported Diff (issue)	Bisected Diff (at culprit)	Duration
Scoped	✅ Success	1c9f9dccb819	✅ RELATED	39.4→64.1 ns (+63%)	37.2→78.4 ns (+111%)	1304s

Total bisection time: 1304s
Success rate: 1/1 tests

Microsoft.Extensions.DependencyInjection.GetServiceIEnumerable.Scoped

• Culprit: 1c9f9dccb819
• Commit Message: Move thin lock acquire/release in CoreCLR to managed code (Move thin lock acquire/release in CoreCLR to managed code #129502)
• Relevance: RELATED
• Explanation: This commit moves Monitor thin lock acquire/release from native CoreCLR code to managed code (PR Move thin lock acquire/release in CoreCLR to managed code #129502), directly affecting lock contention paths. The DI GetServiceIEnumerable.Scoped benchmark exercises scoped service resolution which internally acquires/releases locks on the service provider, making this change a plausible cause of the ~62% regression.

Helix jobs

Job ID	Submitted by bisection	Last status
65f0b827-c7f4-49c9-a0ed-dce4dd6e4850	✅	submitted
d7b5a4aa-8e3a-4a13-89eb-4acf13566615	✅	submitted

Per-commit measurements

Commit	Position	Measurements
19a803d6d08a	baseline	36.680 ns
9cb68cd56462	head	53.900 ns
33db1610a13c	pre-culprit (run 1, 2)	34.460, 37.160 ns
d6d9a97587fb	post-culprit (run 1, 2)	66.910, 78.430 ns

Bisection details

…[earlier output omitted]

This commit moves Monitor.Enter/Exit thin lock paths from native C++ to managed C#. The DI GetServiceIEnumerable.Scoped test uses scoped service providers, which involve IServiceScope disposal and locking. The change is directly RELATED.

BISECTION RESULT:
- Culprit Commit: 1c9f9dccb819214cb9ac469491d675645230400e
- Commit Message: Move thin lock acquire/release in CoreCLR to managed code (#129502)
- Commits Tested: 5
- Confidence: 3
- Commit Relevance: RELATED
- Relevance Explanation: This commit moves Monitor thin lock acquire/release from native CoreCLR code to managed code (PR #129502), directly affecting lock contention paths. The DI GetServiceIEnumerable.Scoped benchmark exercises scoped service resolution which internally acquires/releases locks on the service provider, making this change a plausible cause of the ~62% regression.
- Baseline Value: 37.16 ns (33db1610a13c, the commit immediately before the culprit)
- Culprit Value: 78.43 ns (d6d9a97587fb, the commit immediately after — d6d9a975 only bumps Chrome versions, so the regression comes from 1c9f9dcc)
- Summary: Bisected 4 commits between baseline and head. The regression appears between 33db1610 (37.16 ns) and d6d9a975 (78.43 ns). The intervening commit 1c9f9dcc had no build artifacts, but d6d9a975 only changes BrowserVersions.props (Chrome bump), so the culprit is 1c9f9dcc. Confidence capped at 3/5 due to noisy benchmark (CV=8.29%) and inability to directly measure the culprit commit.

HELIX JOBS:
- 65f0b827-c7f4-49c9-a0ed-dce4dd6e4850
- d7b5a4aa-8e3a-4a13-89eb-4acf13566615

MEASUREMENTS:
- 19a803d6d08a (baseline): 36.68 ns
- 33db1610a13c (pre-culprit, run 1): 34.46 ns
- 33db1610a13c (pre-culprit, run 2): 37.16 ns
- d6d9a97587fb (post-culprit, run 1): 66.91 ns
- d6d9a97587fb (post-culprit, run 2): 78.43 ns
- 9cb68cd56462 (head): 53.90 ns

🤖 Proposed Next Actions

Rule: R4_known_regression_new — Known-cause regression — transfer & notify.

Verified regression attributed to commit 1c9f9dc (finding 5/5, regression 5/5, bisection RELATED). No prior linked autofile issue found.

#	Action	Status	Details
1	Back-reference cause PR	⏭️ Skipped (dry-run)	on culprit PR for 1c9f9dccb819
2	Transfer issue	⏭️ Skipped (dry-run)	→ dotnet/runtime
3	Ping owners	⏭️ Skipped (dry-run)	no owners resolved
4	Remove label	⏭️ Skipped (dry-run)	untriaged

🦆 Pre-bisection Re-analysis (advisory)

✅ Agrees with the pre-bisection plan — advisory only, not applied

Rationale: The single finding has consistent high confidence scores (4/5 finding, 4/5 change), noise=False, a plausible likely commit, and relevant stack trace alignment. One bisection slot for one actionable finding is an appropriate and efficient use of resources.

This critique is advisory in the current configuration and did not change which tests were bisected.

🦆 Re-analysis (advisory)

✅ Agrees with the analysis — advisory only, not applied

Rationale: The bisection converged successfully on commit 1c9f9dc with RELATED relevance and no alignment warning, and the per-finding signal (4/4) is consistent with the overall 5/5 scores once bisection convergence is factored in. No bimodal history or noise indicators undermine the conclusion.

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

---

Generated by PerfTriageAgent on 2026-06-30 10:03 UTC

[LoopedBard3]

Bisection noted the cause as #129502 but it doesn't seem like it directly tested that commit, though that is the most obvious potential cause. I am going to investigate the triage run and am going to go ahead and still transfer this. FYI @VSadov, do you know if #129502 may have been a cause of this?

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-extensions-dependencyinjection
See info in area-owners.md if you want to be subscribed.