[Perf] Windows/x64: 3 Regressions on 6/23/2026 8:41:58 PM +00:00

[performanceautofiler]

Run Information

Name	Value
Architecture	x64
OS	Windows 10.0.22631
Queue	ViperWindows
Baseline	461fd2adbf736b4298d9a0c58ad8dbcecaf83629
Compare	feb1fe23e41b7af2401edbd4230bf11dcb9cfc96
Diff	Diff
Configs	CompilationMode:tiered, RunKind:micro

Regressions in System.Collections.CtorFromCollection<Int32>

Benchmark	Baseline	Test	Test/Base	Test Quality	Edge Detector	Baseline IR	Compare IR	IR Ratio
SortedDictionaryDeepCopy - Duration of single invocation 📝 - Benchmark Source ADX - Test Multi Config Graph	5.50 μs	6.28 μs	1.14	0.03	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 'System.Collections.CtorFromCollection<Int32>*'

Details

System.Collections.CtorFromCollection<Int32>.SortedDictionaryDeepCopy(Size: 512)

ETL Files

Histogram

JIT Disasms

Docs

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

---

Run Information

Name	Value
Architecture	x64
OS	Windows 10.0.22631
Queue	ViperWindows
Baseline	e3ecd30e4d6bfeedec6b4730c8ef87951cfe1f17
Compare	feb1fe23e41b7af2401edbd4230bf11dcb9cfc96
Diff	Diff
Configs	CompilationMode:tiered, RunKind:micro

Regressions in System.Collections.CtorFromCollection<String>

Benchmark	Baseline	Test	Test/Base	Test Quality	Edge Detector	Baseline IR	Compare IR	IR Ratio
Dictionary - Duration of single invocation 📝 - Benchmark Source ADX - Test Multi Config Graph	3.13 μs	5.02 μs	1.60	0.03	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 'System.Collections.CtorFromCollection<String>*'

Details

System.Collections.CtorFromCollection<String>.Dictionary(Size: 512)

ETL Files

Histogram

JIT Disasms

Docs

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

---

Run Information

Name	Value
Architecture	x64
OS	Windows 10.0.22631
Queue	ViperWindows
Baseline	e3ecd30e4d6bfeedec6b4730c8ef87951cfe1f17
Compare	feb1fe23e41b7af2401edbd4230bf11dcb9cfc96
Diff	Diff
Configs	CompilationMode:tiered, RunKind:micro

Regressions in System.Globalization.Tests.StringSearch

Benchmark	Baseline	Test	Test/Base	Test Quality	Edge Detector	Baseline IR	Compare IR	IR Ratio
LastIndexOf_Word_NotFound - Duration of single invocation 📝 - Benchmark Source ADX - Test Multi Config Graph	292.80 ns	310.44 ns	1.06	0.00	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 'System.Globalization.Tests.StringSearch*'

Details

System.Globalization.Tests.StringSearch.LastIndexOf_Word_NotFound(Options: (en-US, OrdinalIgnoreCase, False))

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 SortedDictionaryDeepCopy(Size: 512) — caused by commit 0d1a20f ("JIT: invert oversize loops with their own bounds checks (#129722)"). 3 tests bisected to related culprit commits. ⚠️ Note: One or more tests show bimodal history, but at least one clean test bisected to a related culprit.

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

Likely Cause: 0d1a20fb14109f277df06ebee3f83c964f9dcc61

🤖 Proposed Next Actions: Known-cause regression — already linked — 0 done, 2 dry-run (rule R3_known_regression_with_prior — see Full Analysis for the table). · 🦆 Re-analysis: ⚠️ disputes (overconfident-change-confidence, bimodal-history-risk)

📊 Full Analysis (click to expand)

Summary: Three confirmed regressions detected: Dictionary(String) +60.3%, SortedDictionaryDeepCopy(Int32) +14.2%, and StringSearch.LastIndexOf_Word_NotFound +6.0%. All show clear step changes with no overlap between before/after distributions. Likely cause is commit 0d1a20f ("JIT: invert oversize loops with their own bounds checks"), which modifies loop inversion heuristics affecting loops with bounds checks — directly relevant to collection construction loops and string search loops. Finding confidence 4/5 (excellent historical data, 300 runs per test), regression confidence 4/5 (all three regressions are high-z step changes with a strong JIT candidate).

Issue Overview

• Issue: [Perf] Windows/x64: 3 Regressions on 6/23/2026 8:41:58 PM +00:00 #130046 - [Perf] Windows/x64: 3 Regressions on 6/23/2026 8:41:58 PM +00:00
• Date: 2026-06-23 | Queue: Windows.11.Amd64.Viper.Perf | OS/Arch: Windows/x64
• Commits: 461fd2adbf73 → feb1fe23e41b (19 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 (297–300 runs per test, excellent data quality)

Test Analysis

Test Name	Baseline	Compare	Δ%	μ	σ	n	z	Thresh%	Noise?	Assessment
CtorFromCollection<String>.Dictionary(Size: 512)	3133.09 ns	5021.13 ns	+60.26%	3607.00	378.33	297	3.74	20.98%	N	Step change; far exceeds even inflated threshold
CtorFromCollection<Int32>.SortedDictionaryDeepCopy(Size: 512)	5496.69 ns	6276.41 ns	+14.19%	5474.35	143.68	300	5.58	5.25%	N	Step change; stable baseline, clean shift
StringSearch.LastIndexOf_Word_NotFound(OrdinalIgnoreCase)	292.81 ns	310.44 ns	+6.02%	292.53	1.30	300	13.80	5.00%	N	Textbook step change; ultra-stable history (CV=0.44%)

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

Finding Confidence: 4/5 — Excellent historical data (≥297 runs per test), all tests classified with high-z step changes and no overlap between before/after distributions. Not verified via RunWithBuildAtHash, otherwise would be 5/5.

Candidate Stack Relevance

Commit	Touched Paths (summary)	Relevance	Notes
0d1a20fb1410	src/coreclr/jit/optimizer.cpp	Relevant	JIT loop inversion heuristic change; directly affects CoreCLR code generation for loops with bounds checks
8e67632d800d	src/coreclr/inc/utilcode.h, src/coreclr/vm/eehash.cpp, src/coreclr/inc/dn_xxhash.h	Relevant	HashBytes optimization; affects VM-level string literal interning hash, not managed Dictionary hashing
7ce11b3b0728	src/coreclr/jit/ (SIMD intrinsics)	Relevant	SIMD load/store marking; could affect vectorized code paths
e785632bda5d	src/coreclr/System.Private.CoreLib/src/System/ValueType.cs, src/coreclr/vm/comutilnative.cpp	Relevant	ValueType.GetHashCode fix; narrow scope (nested generics only)
371731cc1a49	src/coreclr/vm/threadstatics.cpp	Relevant	Thread statics alignment fix; one-line else fix, unlikely perf impact

Confirmed Regressions

System.Collections.CtorFromCollection<String>.Dictionary(Size: 512) (+60.26%)

• Delta: 3133.09 ns → 5021.13 ns (+60.26%)
• Historical Context: μ=3607.00 (σ=378.33, n=297); z-score=3.74; adaptive threshold=20.98%
• Assessment: Step change. The high CV (10.49%) reflects a prior improvement that lowered baseline from ~3954 to ~3186 around run 160. The compare value (~5021) and after-distribution (5600–5950) far exceed even the pre-improvement historical high, confirming a genuine and large regression.
• Finding Confidence: 4/5 — Excellent historical data. The bimodal before-distribution is accounted for by the adaptive threshold, yet the regression still vastly exceeds it.
• Regression Confidence: 4/5 — Clear step change, z=3.74 even with inflated σ. Multiple plausible commits cap at 4.
• Likely Cause: 0d1a20fb1410 - "JIT: invert oversize loops with their own bounds checks"
  • Affected Areas: JIT loop optimization, Collections
  • Stack Relevance: Relevant
  • Rationale: This commit modifies JIT loop inversion heuristics in optimizer.cpp, removing the "too big to clone" and "1.25x liberal" size limits, and adding a bailout when nested loops have bounds checks. Dictionary construction from a collection involves inserting each element via a loop with bounds checks (array indexing, hash table resize checks). Changes to how these loops are inverted/cloned could alter generated code quality — e.g., preventing beneficial cloning of an inner resize loop, or causing the outer iteration loop to be inverted in a way that disrupts LICM/CSE. The +60% magnitude suggests a significant code generation change, possibly preventing a loop optimization that previously eliminated bounds checks.
  • Candidates Considered:
    • 0d1a20fb1410 - JIT loop inversion change; directly affects loop codegen for bounds-checked loops
    • 8e67632d800d - HashBytes optimization; affects VM-level EEUnicodeStringLiteralHashTableHelper, not managed Dictionary hashing path
    • 7ce11b3b0728 - SIMD intrinsics marking; could affect vectorized hash/comparison operations
• Verification Status: Not verified

System.Collections.CtorFromCollection<Int32>.SortedDictionaryDeepCopy(Size: 512) (+14.19%)

• Delta: 5496.69 ns → 6276.41 ns (+14.19%)
• Historical Context: μ=5474.35 (σ=143.68, n=300); z-score=5.58; adaptive threshold=5.25%
• Assessment: Clear step change. Before series stable (CV=2.63%), all 39 after values cluster at 6240–6403 with no overlap to before distribution. Two isolated spikes in before data (7580, 6042, 6047) are transient noise.
• Finding Confidence: 4/5 — Excellent data quality, 300 historical runs, low variance.
• Regression Confidence: 4/5 — Strong z-score (5.58), clean step change, stable history. Multiple candidates cap at 4.
• Likely Cause: 0d1a20fb1410 - "JIT: invert oversize loops with their own bounds checks"
  • Affected Areas: JIT loop optimization, Collections
  • Stack Relevance: Relevant
  • Rationale: SortedDictionary deep copy involves iterating through tree nodes and performing comparisons/insertions, which contain loops with bounds checks. The JIT loop inversion heuristic change could alter code generation for these loops, preventing cloning that previously eliminated bounds checks or disrupting other optimizations. The +14% magnitude is consistent with losing a loop optimization on a tight allocation/copy path.
  • Candidates Considered:
    • 0d1a20fb1410 - JIT loop inversion; affects loop codegen for tree traversal/copy loops
    • e785632bda5d - ValueType.GetHashCode fix; narrow scope (nested generics), Int32 doesn't go through ValueType override
    • 7ce11b3b0728 - SIMD intrinsics; less likely to affect tree copy operations
• Verification Status: Not verified

System.Globalization.Tests.StringSearch.LastIndexOf_Word_NotFound(OrdinalIgnoreCase) (+6.02%)

• Delta: 292.81 ns → 310.44 ns (+6.02%)
• Historical Context: μ=292.53 (σ=1.30, n=300); z-score=13.80; adaptive threshold=5.00%
• Assessment: Textbook step change. Historically ultra-stable (CV=0.44%). Before values tightly bounded 290–298, all 39 after values tightly bounded 310–317 with zero overlap. Extremely high statistical significance.
• Finding Confidence: 4/5 — Excellent data quality, ultra-stable history makes signal unmistakable.
• Regression Confidence: 4/5 — Extreme z-score (13.80) on an ultra-stable test. Corroborated by the JIT loop change affecting string comparison loops. Multiple candidates cap at 4.
• Likely Cause: 0d1a20fb1410 - "JIT: invert oversize loops with their own bounds checks"
  • Affected Areas: JIT loop optimization, Globalization/String search
  • Stack Relevance: Relevant
  • Rationale: LastIndexOf with OrdinalIgnoreCase involves a character-by-character comparison loop scanning backward through the string, with bounds checks on array/span indices. The JIT loop inversion change modifies how loops with bounds checks are inverted and cloned. If the search loop was previously benefiting from cloning (which eliminates bounds checks in the fast path), the new heuristic that bails out when nested loops have bounds checks could prevent this optimization. The +6% on a sub-300ns benchmark with near-zero variance is highly significant and consistent with losing a bounds check elimination.
  • Candidates Considered:
    • 0d1a20fb1410 - JIT loop inversion; directly affects loop codegen for string search inner loops
    • 8e67632d800d - HashBytes; unrelated to string comparison/search operations
    • 7ce11b3b0728 - SIMD intrinsics; could affect vectorized OrdinalIgnoreCase paths if SIMD is used for case-insensitive comparison
• Verification Status: Not verified

Open Questions

• Confidence Limitations: 19 commits in range; multiple JIT/runtime commits are plausible candidates. Bisection or RunWithBuildAtHash verification would confirm attribution.
• Verification Needed: Bisection recommended to confirm 0d1a20f as the cause. Testing the baseline commit (461fd2a) against the JIT commit and the commit just before it would isolate the impact. The +60% Dictionary(String) regression is particularly striking and may have a different or compound cause.
• Dictionary(String) magnitude: The +60% regression is unusually large for a JIT heuristic change. It's possible this test is also affected by another commit (e.g., 8e67632 HashBytes changes or 7ce11b3 SIMD changes) or that the loop inversion change triggers a particularly pathological code generation pattern for Dictionary's resize/insert path.

Recommended Actions

1. Bisection: Run bisection on commits 461fd2adbf73...feb1fe23e41b using RunWithBuildAtHash with all three tests to isolate the culprit commit(s).
2. Verification: Verify regression with RunWithBuildAtHash on commit 0d1a20fb1410 vs its parent d61394d4163a to confirm the JIT loop inversion change is responsible.
3. JIT disasm comparison: Compare JIT disassembly for Dictionary.ctor and LastIndexOf between baseline and compare to identify specific codegen differences (loop cloning, bounds check elimination).
4. Profiling: If bisection confirms 0d1a20f, collect hardware counters (branch mispredictions, cache misses) with collectHardwareCounters=true to characterize the regression mechanism.

Bisection Results

Test	Status	Culprit Commit	Relevance	Reported Diff (issue)	Bisected Diff (at culprit)	Duration
SortedDictionaryDeepCopy(Size: 512)	✅ Success	0d1a20fb1410	✅ RELATED	5.5→6.3 μs (+14%)	5.4→6.4 μs (+17%)	1374s
Dictionary(Size: 512)	✅ Success	0d1a20fb1410	✅ RELATED	3.1→5.0 μs (+60%)	3.2→4.9 μs (+56%)	1284s
LastIndexOf_Word_NotFound(Options: (e...	✅ Success	0d1a20fb1410	✅ RELATED	292.8→310.4 ns (+6%)	291.6→310.4 ns (+6%)	5551s

Total bisection time: 8209s
Success rate: 3/3 tests

System.Collections.CtorFromCollection.SortedDictionaryDeepCopy(Size: 512)

• Culprit: 0d1a20fb1410
• Commit Message: JIT: invert oversize loops with their own bounds checks (JIT: invert oversize loops with their own bounds checks #129722)
• Relevance: RELATED
• Explanation: This commit modifies JIT loop inversion heuristics in src/coreclr/jit/optimizer.cpp (optTryInvertWhileLoop), relaxing size limits and changing when loops with bounds checks are inverted/cloned. SortedDictionary construction involves tree traversal loops that are directly affected by JIT loop optimization decisions. The changed code generation path plausibly explains the ~14% regression in this collection benchmark.

Helix jobs

Job ID	Submitted by bisection	Last status
4085bd56-f8b0-4f6c-b2ac-5e7873c1789e	✅	submitted
62a75367-2c24-4855-a353-765f6794d470	✅	submitted
a0451b03-b9da-41dd-b333-d438d52d611c	✅	completed
d0d898a6-d416-4565-a7f1-41772a325c67	✅	completed

Per-commit measurements

Commit	Position	Measurements
e785632bda5d	quarter, idx 4	5.566 μs
b5e2bef187f9	idx 9	5.447, 5.447 μs
0d1a20fb1410	idx 11	6.395 μs
a79c6fbd8514	idx 12	6.266 μs
df7a83ee3fa9	idx 13	6.276 μs
5fcd603a0a22	idx 15	6.253 μs
371731cc1a49	idx 17	6.248 μs

Bisection details

…[earlier output omitted]

d61394d (idx 10): didn't build — "Port System.Net.Http to OpenBSD" (completely unrelated)

• 0d1a20f (idx 11): 6394.52 ns ✗ — "JIT: invert oversize loops with their own bounds checks" (optimizer.cpp)

The JIT commit 0d1a20fb modifies loop inversion heuristics in optTryInvertWhileLoop, which directly affects code generation for loops. Since d61394d4 only touches OpenBSD networking/crypto code (unrelated to collections on Windows), 0d1a20fb is the culprit.

The delta (947.94 ns) is ~3.3σ above the noise floor (2σ = 287.36), so this is statistically significant.

BISECTION RESULT:
- Culprit Commit: 0d1a20fb14109f277df06ebee3f83c964f9dcc61
- Commit Message: JIT: invert oversize loops with their own bounds checks (#129722)
- Commits Tested: 7
- Confidence: 4
- Commit Relevance: RELATED
- Relevance Explanation: This commit modifies JIT loop inversion heuristics in src/coreclr/jit/optimizer.cpp (optTryInvertWhileLoop), relaxing size limits and changing when loops with bounds checks are inverted/cloned. SortedDictionary construction involves tree traversal loops that are directly affected by JIT loop optimization decisions. The changed code generation path plausibly explains the ~14% regression in this collection benchmark.
- Baseline Value: 5446.58 ns
- Culprit Value: 6394.52 ns
- Summary: Bisected 19 commits across 3 Helix jobs, narrowing from Q1-Q4 to a 2-commit window. The skipped commit (d61394d4, OpenBSD porting) is unrelated to collections performance, confirming the JIT optimizer change as the culprit.

HELIX JOBS:
- 4085bd56-f8b0-4f6c-b2ac-5e7873c1789e
- 62a75367-2c24-4855-a353-765f6794d470
- a0451b03-b9da-41dd-b333-d438d52d611c
- d0d898a6-d416-4565-a7f1-41772a325c67

MEASUREMENTS:
- e785632bda5d (quarter, idx 4): 5566.33 ns
- b5e2bef187f9 (mid, idx 9): 5446.58 ns
- 0d1a20fb1410 (idx 11): 6394.52 ns
- a79c6fbd8514 (idx 12): 6265.53 ns
- df7a83ee3fa9 (idx 13): 6276.09 ns
- 5fcd603a0a22 (idx 15): 6253.33 ns
- 371731cc1a49 (idx 17): 6247.59 ns

System.Collections.CtorFromCollection.Dictionary(Size: 512)

• Culprit: 0d1a20fb1410
• Commit Message: JIT: invert oversize loops with their own bounds checks (JIT: invert oversize loops with their own bounds checks #129722)
• Relevance: RELATED
• Explanation: The commit modifies JIT loop inversion heuristics in src/coreclr/jit/optimizer.cpp, relaxing size limits and adding a bail-out when nested loops have their own bounds checks. Dictionary construction from a collection of 512 strings involves loops with bounds checks, and this change likely prevents beneficial loop inversion+cloning that was previously applied, causing the ~56% regression.

Helix jobs

Job ID	Submitted by bisection	Last status
c3c6e002-518c-4842-afff-700cb72944d6	✅	submitted
6f2f4ba9-5dd0-4e56-8f4c-3489efa4e9e3	✅	completed
6a30b232-0433-460d-8b84-77d6be8bb3bd	✅	submitted
6092226d-6468-4412-a230-a8078eb51770	✅	submitted

Per-commit measurements

Commit	Position	Measurements
e785632bda5d	baseline-region	3.144 μs
0d1a20fb1410	culprit	4.921 μs
371731cc1a49	post-culprit	4.979 μs
5fcd603a0a22	post-culprit	4.944 μs
a79c6fbd8514	post-culprit	4.966 μs
b5e2bef187f9	last-good	3.156 μs
df7a83ee3fa9	post-culprit	5.953 μs

Bisection details

…[earlier output omitted]

--|-------------|--------|
| e785632 | 4 | 3144 | ✓ baseline |
| b5e2bef | 9 | 3156 | ✓ baseline |
| 0d1a20f | 11 | 4921 | ✗ regressed |
| a79c6fb | 12 | 4966 | ✗ regressed |
| df7a83e | 13 | 5953 | ✗ regressed |
| 5fcd603 | 15 | 4944 | ✗ regressed |
| 371731c | 17 | 4979 | ✗ regressed |

Step change: ~3150 → ~4920 ns (+56%), well above the 2σ noise floor of 757 ns. The culprit commit modifies src/coreclr/jit/optimizer.cpp — JIT loop inversion heuristics that directly affect how loops with bounds checks (like Dictionary construction) are optimized.

BISECTION RESULT:
- Culprit Commit: 0d1a20fb14109f277df06ebee3f83c964f9dcc61
- Commit Message: JIT: invert oversize loops with their own bounds checks (#129722)
- Commits Tested: 7
- Confidence: 4
- Commit Relevance: RELATED
- Relevance Explanation: The commit modifies JIT loop inversion heuristics in src/coreclr/jit/optimizer.cpp, relaxing size limits and adding a bail-out when nested loops have their own bounds checks. Dictionary construction from a collection of 512 strings involves loops with bounds checks, and this change likely prevents beneficial loop inversion+cloning that was previously applied, causing the ~56% regression.
- Baseline Value: 3155.60 ns
- Culprit Value: 4921.47 ns
- Summary: Bisected 19 commits across 3 Helix jobs, testing 7 commits total. Clear step change from ~3156 ns to ~4921 ns between b5e2bef (good) and 0d1a20fb (regressed), with the skipped commit d61394d being an unrelated OpenBSD port with no build artifacts.

HELIX JOBS:
- c3c6e002-518c-4842-afff-700cb72944d6
- 6f2f4ba9-5dd0-4e56-8f4c-3489efa4e9e3
- 6a30b232-0433-460d-8b84-77d6be8bb3bd
- 6092226d-6468-4412-a230-a8078eb51770

MEASUREMENTS:
- e785632bda5d (baseline-region): 3144.12 ns
- b5e2bef187f9 (last-good): 3155.60 ns
- 0d1a20fb1410 (culprit): 4921.47 ns
- a79c6fbd8514 (post-culprit): 4966.00 ns
- df7a83ee3fa9 (post-culprit): 5952.93 ns
- 5fcd603a0a22 (post-culprit): 4943.84 ns
- 371731cc1a49 (post-culprit): 4978.60 ns

System.Globalization.Tests.StringSearch.LastIndexOf_Word_NotFound(Options: (en-US, OrdinalIgnoreCase, False))

• Culprit: 0d1a20fb1410
• Commit Message: JIT: invert oversize loops with their own bounds checks (JIT: invert oversize loops with their own bounds checks #129722)
• Relevance: RELATED
• Explanation: This commit modifies src/coreclr/jit/optimizer.cpp, changing the loop inversion heuristic in optTryInvertWhileLoop. It relaxes size limits for loops with bounds checks and changes how nested loop bounds checks are handled. JIT loop optimization changes directly affect how string search loops are compiled and can alter performance of hot paths like LastIndexOf with OrdinalIgnoreCase. The skipped commit d61394d (OpenBSD port) only modifies System.Net.Http and native OpenSSL shim code, making it irrelevant to this Windows globalization benchmark.

Helix jobs

Job ID	Submitted by bisection	Last status
dc24b7bf-4f53-49f9-8755-eb4275f5f728	✅	submitted
f851c3fe-420c-47eb-923f-686ef0817e52	✅	submitted
d400fb01-bb28-4085-aa41-1a66284db753	✅	completed

Per-commit measurements

Commit	Position	Measurements
a79c6fbd8514	index 12	312.490 ns
5fcd603a0a22	index 15	313.980 ns
371731cc1a49	index 17	313.980 ns
0d1a20fb1410	culprit	310.380 ns
b5e2bef187f9	mid	291.600 ns
e785632bda5d	quarter	291.450 ns

Bisection details

…[earlier output omitted]

Summary of measurements:

• index 4 (e785632): 291.45 ns ✓
• index 9 (b5e2bef): 291.60 ns ✓ (last good)
• index 10 (d61394d): no build (OpenBSD port)
• index 11 (0d1a20f): 310.38 ns ✗ (first bad — JIT loop inversion change)
• index 12 (a79c6fb): 312.49 ns ✗
• index 15 (5fcd603): 313.98 ns ✗
• index 17 (371731c): 313.98 ns ✗

BISECTION RESULT:
- Culprit Commit: 0d1a20fb14109f277df06ebee3f83c964f9dcc61
- Commit Message: JIT: invert oversize loops with their own bounds checks (#129722)
- Commits Tested: 6
- Confidence: 4
- Commit Relevance: RELATED
- Relevance Explanation: This commit modifies `src/coreclr/jit/optimizer.cpp`, changing the loop inversion heuristic in `optTryInvertWhileLoop`. It relaxes size limits for loops with bounds checks and changes how nested loop bounds checks are handled. JIT loop optimization changes directly affect how string search loops are compiled and can alter performance of hot paths like `LastIndexOf` with OrdinalIgnoreCase. The skipped commit d61394d (OpenBSD port) only modifies System.Net.Http and native OpenSSL shim code, making it irrelevant to this Windows globalization benchmark.
- Baseline Value: 291.60 ns
- Culprit Value: 310.38 ns
- Summary: Bisected 19 commits across 3 Helix jobs. The regression (~6.4%, well above the 2σ noise floor of 2.6 ns) appears precisely at the JIT loop inversion heuristic change by Andy Ayers. The preceding commit (d61394d, OpenBSD port) had no build artifacts but is clearly unrelated to this test.

HELIX JOBS:
- dc24b7bf-4f53-49f9-8755-eb4275f5f728
- f851c3fe-420c-47eb-923f-686ef0817e52
- d400fb01-bb28-4085-aa41-1a66284db753

MEASUREMENTS:
- e785632bda5d (quarter): 291.45 ns
- b5e2bef187f9 (mid): 291.60 ns
- a79c6fbd8514 (index 12): 312.49 ns
- 5fcd603a0a22 (index 15): 313.98 ns
- 371731cc1a49 (index 17): 313.98 ns
- 0d1a20fb1410 (culprit): 310.38 ns

🤖 Proposed Next Actions

Rule: R3_known_regression_with_prior — Known-cause regression — already linked.

Verified regression attributed to commit 0d1a20f; an autofile issue is already linked: #116486.

#	Action	Status	Details
1	Append related regression	⏭️ Skipped (dry-run)	on #116486
2	Remove label	⏭️ Skipped (dry-run)	untriaged

🦆 Pre-bisection Re-analysis (advisory)

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

Rationale: All three findings show consistent 4/5 change confidence, point to the same likely commit (0d1a20f), and have relevant stack traces. Although bimodal history is flagged, the per-finding signal uniformly classifies them as non-noise with solid confidence, and the candidate set exactly matches the actionable findings with no extraneous or missing tests.

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

🦆 Re-analysis (advisory)

⚠️ Disputes the analysis — advisory only, not applied

Flags: overconfident-change-confidence, bimodal-history-risk

Rationale: All three bisections converge on the same commit with no alignment warnings, which strongly supports the culprit and justifies the 5/5 finding confidence. However, the packet flags bimodal history as True, meaning these benchmarks have historically oscillated between modes; this raises the possibility that the observed shift is a mode-switch rather than a sustained regression. The individual per-finding change confidences are already a cautious 4/5, yet the overall change confidence was elevated to 5/5 despite the bimodal flag — that bump is not justified. Lowering overall change confidence to…

Suggested confidence: Change Confidence → 4/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-06-30 11:54 UTC

[LoopedBard3]

Likely due #130046, FYI @AndyAyersMS.