Use closure vs parameter in GetOrAdd type methods

[TahirAhmadov]

In many places in BCL and elsewhere, there are methods such as this:

var dict = new ConcurrentDictionary<int, int>();
int input = 6;
int res = dict.GetOrAdd(input, input2 => input2 * 2);

Note the parameter of the delegate (lambda) named input2. Am I correct in understanding that it's added to avoid using the input as a closure, for performance? Was there testing done to justify this as a valuable enough addition?

[gfoidl]

The main purpose is to provide a "value factory", that can construct the value to be added to the dictionary, based on the given key.
This is very handy when the object to be constructed is costly, so it doesn't need to be done beforehands.

E.g.

private ConcurrentDictionary<int, MyHeavyType> _dict = new();

public MyHeavyType Naive(int key, Func<int, MyHeavyType> valueFactory)
{
    // If the key is already present in the dictionary, the construction of MyHeavyType is done unnecessarily.
    MyHeavyType value = valueFactory(key);
    return _dict.GetOrAdd(key, value);
}

public MyHeavyType Better(int key, Func<int, MyHeavyType> valueFactory)
{
    // The construction of MyHeavyType is only done when needed to do.
    return _dict.GetOrAdd(key, valueFactory);
}

[TahirAhmadov]

Oh yes, my question was this - the way it's done now, is it better than below from performance perspective?

public MyHeavyType Better(int key, Func<int, MyHeavyType> valueFactory)
{
    // The construction of MyHeavyType is only done when needed to do.
    return _dict.GetOrAdd(key, _ => valueFactory(key)); // using discard _ to demonstrate my point - 
    // I already have the key in the closure, so why not just use that?
}

[gfoidl]

so why not just use that?

This creates a closure over key and valueFactory -- look at the IL or with a tool like ILSpy (with C# 1 selected) to see the "display class".
With the aforementioned approach / the overload with the value factory this can be avoided.

For some numbers to see the effect:

|                             Method |      Mean |     Error |    StdDev | Ratio | RatioSD |  Gen 0 | Allocated |
|----------------------------------- |----------:|----------:|----------:|------:|--------:|-------:|----------:|
|                              Naive | 13.297 ns | 0.2010 ns | 0.1880 ns |  1.00 |    0.00 | 0.0076 |      24 B |
|                             Better |  9.580 ns | 0.0641 ns | 0.0500 ns |  0.72 |    0.01 |      - |         - |
| BetterWithClosureSoNotReallyBetter | 21.739 ns | 0.1849 ns | 0.1544 ns |  1.64 |    0.03 | 0.0306 |      96 B |

return _dict.GetOrAdd(key, valueFactory);

Here is no closure over key or anything else.

Benchmark code

using System.Collections.Concurrent;
using BenchmarkDotNet.Attributes;
using BenchmarkDotNet.Running;

BenchmarkRunner.Run<Bench>();

[MemoryDiagnoser]
public class Bench
{
    private readonly ConcurrentDictionary<int, MyHeavyType> _dic = new();
    private readonly Func<int, MyHeavyType> _valueFactory = _ => new MyHeavyType();
    private int _key = 42;

    [Benchmark(Baseline = true)]
    public MyHeavyType Naive() => this.Naive(_key, _valueFactory);

    private MyHeavyType Naive(int key, Func<int, MyHeavyType> valueFactory)
    {
        MyHeavyType value = valueFactory(key);
        return _dic.GetOrAdd(key, value);
    }

    [Benchmark]
    public MyHeavyType Better() => this.Better(_key, _valueFactory);

    private MyHeavyType Better(int key, Func<int, MyHeavyType> valueFactory)
    {
        return _dic.GetOrAdd(key, valueFactory);
    }

    [Benchmark]
    public MyHeavyType BetterWithClosureSoNotReallyBetter() => this.BetterWithClosureSoNotReallyBetter(_key, _valueFactory);

    private MyHeavyType BetterWithClosureSoNotReallyBetter(int key, Func<int, MyHeavyType> valueFactory)
    {
        return _dic.GetOrAdd(key, _ => valueFactory(key));
    }
}

public class MyHeavyType { }

[TahirAhmadov]

Oh man, I didn't mean to make you do this test, was just wondering if this was already done previously. I suspected it was slower but your results demonstrate it clearly. Thank you.

[gfoidl]

You're welcome 😃

Note also that VS has a cool feature when hovering with the mouse over the =>