In this post, I would like to share information about a small, but, in my opinion, very, very useful project , in which Stefán Jökull Sigurðarson adds all the IoC containers known to him that have migrated to .NET Core, and using BenchmarkDotNet , measures the instance resolving performance. I did not miss the opportunity to participate in this competition and I am with my small project FsContainer .

1.2.0

After the project was migrated to .NET Core (I want to note that it turned out to be absolutely not difficult), to say that I was not discouraged, so to say nothing, and this was due to the fact that one of the three measurements my container did not pass. In the literal meaning of this word, the measurement simply lasted over 20 minutes and did not end.

The reason was in this section of the code:

public object Resolve(Type type) { var instance = _bindingResolver.Resolve(this, GetBindings(), type); if (!_disposeManager.Contains(instance)) { _disposeManager.Add(instance); } return instance; } 

If you think about it, the basic principle of the work of benchmarks is the measurement of the number of operations performed per unit of time (optional memory consumption), which means that the Resolve method is run as many times as possible. You may notice that after the resolve, the resulting instance is added to the _disposeManager for further destruction in the case of container.Dispose() . Since inside the implementation is a List<object> , instances in which are added by checking on Contains , then you can guess that there are 2 side-effects at once:

1. Each new instance created using the Contains check will compute GetHashCode and search for a duplicate among previously added ones;
2. Since each new instance created will always be unique (resolve tested with TransientLifetimeManager tested), then the size of the List<object> will constantly increase by allocating a new, twice larger memory area and copying previously added elements into it (to add a million copies of the memory allocation operation) and copies will be called at least 20 times);

Frankly, I'm not sure which solution is the most correct in this case, because in real life it’s hard for me to imagine when one container will hold millions of references to previously created instances, so I solved only half of the problem, adding a (quite logical) restriction to Adding to the _disposeManager only those objects that implement IDisposable .

 if (instance is IDisposable && !_disposeManager.Contains(instance)) { _disposeManager.Add(instance); } 

As a result, the measurement was completed in a fairly reasonable time and gave the following results:

I, of course, did not become pleased with them and began to search for further ways of optimization.

1.2.1

In the current version of the container, the definition of the required constructor and the arguments required for it is unchanged, therefore, this information can be cached and henceforth do not waste processor time. The result of this optimization is the addition of ConcurrentDictionary , the key of which is the requested type ( Resolve<T> ), and the values ​​are the constructor and the arguments that will be used to create the instance directly.

 private readonly IDictionary<Type, Tuple<ConstructorInfo, ParameterInfo[]>> _ctorCache = new ConcurrentDictionary<Type, Tuple<ConstructorInfo, ParameterInfo[]>>(); 

Judging by the measurements, such a simple operation increased productivity by more than 30%:

1.2.2

By taking measurements, BenchmarkDotNet notifies the user that this or that assembly may not be optimized (compiled in a Debug configuration). I couldn’t understand for a long time why this message was highlighted in the project, where the container was connected via nuget package and what my surprise was when I saw a possible list of parameters for nuget pack:

 nuget pack MyProject.csproj -properties Configuration=Release 

It turns out that all this time I was building a package in the Debug configuration, which judging by the updated measurement results, slowed down the performance by as much as 25%.

1.2.3

Another optimization was the caching of the activator function, which is compiled using Expression:

 private readonly IDictionary<Type, Func<object[], object>> _activatorCache = new ConcurrentDictionary<Type, Func<object[], object>>(); 

The universal function takes as arguments the ConstructorInfo and the argument array ParameterInfo[] , and returns a strongly typed lambda as the result:

 private Func<object[], object> GetActivator(ConstructorInfo ctor, ParameterInfo[] parameters) { var p = Expression.Parameter(typeof(object[]), "args"); var args = new Expression[parameters.Length]; for (var i = 0; i < parameters.Length; i++) { var a = Expression.ArrayAccess(p, Expression.Constant(i)); args[i] = Expression.Convert(a, parameters[i].ParameterType); } var b = Expression.New(ctor, args); var l = Expression.Lambda<Func<object[], object>>(b, p); return l.Compile(); } 

I agree that a logical continuation of this solution should be to compile the entire Resolve function, not just the Activator, but even in the current implementation this introduced a 10% acceleration, thus allowing to take a confident 5th place:

1.2.4

Already after the publication of the article, @turbanoff noticed that in the case of ConcurrentDictionary performance of the GetOrAdd method GetOrAdd higher than that of ContainsKey / Add, for which he thanks a GetOrAdd . The results of the measurements are presented below:

Before:

 if (!_activatorCache.ContainsKey(concrete)) { _activatorCache[concrete] = GetActivator(ctor, parameters); } 

After:

 var activator = _activatorCache.GetOrAdd(concrete, x => GetActivator(ctor, parameters)); 

PS

As an experiment, I decided to measure the time of creation of objects using different designs. The project itself is available on Github , and you can see the results below. For the sake of completeness, only the activation method is missing through the generation of IL instructions as close as possible to the Direct method. It is this method that uses containers from the top 4, which allows them to achieve such impressive results.