[Perf] Windows/x64: 1 Regression on 11/18/2024 8:23:46 PM

[performanceautofiler]

Run Information

Name	Value
Architecture	x64
OS	Windows 10.0.22631
Queue	ViperWindows
Baseline	234e2f7ec5dd315014f31574719900c0715f9477
Compare	e33be4d53ab951272c9161c50b549e5e7db60262
Diff	Diff
Configs	CompilationMode:tiered, RunKind:micro

Regressions in System.Collections.CtorDefaultSize<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	16.33 ns	19.85 ns	1.22	0.16	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.CtorDefaultSize<String>*'

System.Collections.CtorDefaultSize<String>.Dictionary

ETL Files

Histogram

JIT Disasms

Docs

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

[LoopedBard3]

Potentially: #109882 in commit range: 2c7c6bf...f3cdf14. Would the commit make sense as having caused this regression @AaronRobinsonMSFT?

[AaronRobinsonMSFT]

@LoopedBard3 It is entirely possible the referenced PR contributed to this. The instantiation of the Dictionary<string, string> does have some special cased code paths, perhaps indirectly sensitive to my changes, and that could be why this is occurring there and not with other types. Regardless, this change is for simplifying and removing a troublesome code pattern in the runtime. Minor regressions like this, < 5 ns, seem reasonable for the benefit of the effort.