.NET: Iterating collections via interfaces can impact peformance

[michael]

Dear Igniters,

Whilst checking out BenchmarkDotNet (thanks Pavel!) I came across this
issue [1].  There is some useful discussion in [2] under "Dictionary
vs IDictionary".

It seems that iterating collections via their interfaces has
performance implications, specifically that iterating interfaces can
cause unnecessary memory allocations and therefore GC, and the
MoveNext and Current functions being accessed by virtual interface
calls, rather than inlineable non-virtual calls.

As there are a number of instances of iterating collections via
interface in the Ignite.NET codebase, some of them in performance
critical areas like the Binary marshaller, perhaps we should
investigate changing those iterations to use the concrete types?

Regards
Mike

[1] https://github.com/dotnet/coreclr/issues/1579
[2]
http://mattwarren.org/2016/02/17/adventures-in-benchmarking-memory-allocations/

[Pavel Tupitsyn]

Hi Mike,

I'm aware of this issue and usually try to keep an eye on it.

Can you list your findings?
I see BinaryProcessor.PutBinaryTypes and Marshaller.OnBinaryTypesSent,
anything else?

Pavel

On Wed, Aug 30, 2017 at 10:41 AM, <[hidden email]> wrote:

>
> Dear Igniters,
>
> Whilst checking out BenchmarkDotNet (thanks Pavel!) I came across this
> issue [1].  There is some useful discussion in [2] under "Dictionary
> vs IDictionary".
>
> It seems that iterating collections via their interfaces has
> performance implications, specifically that iterating interfaces can
> cause unnecessary memory allocations and therefore GC, and the
> MoveNext and Current functions being accessed by virtual interface
> calls, rather than inlineable non-virtual calls.
>
> As there are a number of instances of iterating collections via
> interface in the Ignite.NET codebase, some of them in performance
> critical areas like the Binary marshaller, perhaps we should
> investigate changing those iterations to use the concrete types?
>
> Regards
> Mike
>
> [1] https://github.com/dotnet/coreclr/issues/1579
> [2]
> http://mattwarren.org/2016/02/17/adventures-in-benchmarking-
> memory-allocations/
>
>