Is it possible to describe "typical" performance degradations of using abstract types, like IReadOnlyDictionary<T,T> over Dictionary<T,T>

[taylorchasewhite]

Type of issue

Missing information

Description

I appreciate the code analysis warnings introduced in .NET 8, but I'm struggling with this one. In general, my firm likes to enforce read-only usage of collections, via IReadOnlyList and IReadOnlyDictionary, and obviously this warning conflicts with that objective. It would be helpful to many folks getting this warning to understand the extent of the performance degradation from using an interface declaration vs. a concrete type declaration, even if the description of that degradation is very brief and broad (e.g. it's on average 10% slower, or 50% slower to call the virtual method).

Page URL

https://learn.microsoft.com/en-us/dotnet/fundamentals/code-analysis/quality-rules/ca1859

Content source URL

https://github.com/dotnet/docs/blob/main/docs/fundamentals/code-analysis/quality-rules/ca1859.md

Document Version Independent Id

c8f7f102-2398-9acc-71b8-b0f848a05b92

Article author

gewarren

Metadata

• ID: 0e2d460f-c6f3-1e26-d932-b7e69746e513
• Service: dotnet-fundamentals

[shravan2x]

From https://devblogs.microsoft.com/dotnet/performance-improvements-in-net-8/, it appears to be ~20%. That said, at a difference of 0.3ns, I'll personally stick to IReadOnlyXyz types except on the hottest of paths.

[daiplusplus]

@shravan2x it appears to be ~20%.

I was dealing with CA1859: Use concrete types when possible for improved performance warnings today so I thought I should look into it and get some hard numbers - because I don't know exactly where/how @shravan2x derived that "~20%" performance figure from Stephen Toub's article - (I'm guessing it's from the section on PGO improvements, but I'm not confident I could correctly interpret the limited data posted in the article).

...so anyway, I'll admit I was feeling lazy/tired/hungry and asked ChatGPT to generate the initial Benchmark.net program for me, it helpfully included some profiing test-cases that I didn't think of at all (and without any hallucinations either), so credit goes where credit is due - I merely tidied it up and ran the thing to get the numbers.

The program and CSV results are available in this gist: https://gist.github.com/daiplusplus/72aa75dbb3d7b1cd6746c79a60e0e3f1

And some hastily made Excel screenshots:

Here's the improvements from net48 to net6.0 to net8.0:

Here's the benchmark perf difference between the IReadOnlyDictionary<K,V> interface vs. DIctionary<K,V> object references in net48, net6.0, and net8.0:

I'm not a benchmarking expert, and it wouldn't surprise me if there's a major methodological flaw in my approach, but so-far it looks like I can safely say:

• Using IReadOnlyDictionary<K,V> over Dictionary<K,V> does not harm performance significantly - or even at all given the margin-of-errors here..
• ...unless your application does a lot of foreach loops over Dictionary.GetEnumerator().
  • and I suspect that's because IReadOnlyDictionary<K,V> has to return an IEnumerator<Kvp<K,V>> whereas Dictionary<K,V> can return a non-reference type enumerator.

...so I think there's actually a minor methodological flaw in my approach in that I'm basically comparing IEnumerator<Kvp<K,V>> to struct Dictionary<K,V>.Enumerator - and I don't know if this is an appreciable problem or not.

AFAIK, the only real solution to this problem is for .NET generics to support interface associated types that are known in-advance to be value-types - and I don't know enough constructive type theory to suggest a way to do that.