この記事では、小さいながらも非常に有用なプロジェクトについて情報を共有したいと思います。StefánJökullSigurðarsonは、.NET Coreに移行したことがわかっているすべてのIoCコンテナーを追加し、 BenchmarkDotNetを使用したインスタンス測定解決を使用しますパフォーマンス。 私はこのコンペティションに参加する機会を逃しませんでした 。私は自分の小さなプロジェクトFsContainerに参加しました 。

1.2.0

プロジェクトが.NET Coreに移行された後（私はそれが絶対に難しくないことが判明したことに注意したい）、私は失望しなかったと言って、それは何も言わないことを意味し、これは3つの測定値の1つが私のコンテナーを通過しなかったという事実によるものでした。 この言葉の直接的な意味では、測定は単純に20分以上続き、終了しませんでした。

その理由は次のコードセクションにあります。

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

考えてみると、ベンチマーク操作の主な原則は、単位時間（オプションのメモリ消費量）ごとに実行される操作の数を測定することです。つまり、 Resolveメソッドはできるだけ多く実行されます。 container.Dispose()場合、解決後、結果のインスタンスが_disposeManagerに追加されてさらに破棄されることに気付くかもしれません。 なぜなら 実装の内部にはList<object> 、そのインスタンスはContainsチェックすることで追加さContains 、すぐに2つの副作用があると推測できContains ：

1. Containsチェックを使用して新しく作成された各インスタンスは、 GetHashCodeを計算し、以前に追加されたインスタンスの重複を探します。
2. なぜなら 新しく作成された各インスタンスは常に一意になり（解決はTransientLifetimeManagerでテストされました）、 List<object>サイズは、メモリの新しい2倍の部分を割り当て、 以前に追加された要素をコピーして （メモリ割り当て操作の100万インスタンスを追加するため）常に増加しますコピーは少なくとも20回呼び出されます）;

率直に言って、この場合、どのソリューションが最も正しいかわかりません。実際には、1つのコンテナが以前に作成されたインスタンスへの数百万のリンクを保持することを想像するのは難しいため、（かなり論理的な）制限を追加することで問題の半分しか解決しませんでしたIDisposableを実装するオブジェクトのみを_disposeManager追加し_disposeManager 。

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

その結果、測定はかなり許容できる時間で完了し、次の結果が得られました。

もちろん、私はそれらに満足しておらず、さらなる最適化方法を探し始めました。

1.2.1

コンテナの現在のバージョンでは、必要なコンストラクターとそれに必要な引数の定義は変更されていないため、この情報をキャッシュでき、今後CPU時間を浪費することはありません。 この最適化の結果、 ConcurrentDictionaryが追加され、そのキーは要求されたタイプ（ Resolve<T> ）であり、値は直接インスタンス化するために使用されるコンストラクターと引数です。

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

行われた測定から判断すると、このような単純な操作により、生産性が30％以上向上しました。

1.2.2

測定を行うとき、BenchmarkDotNetは、アセンブリが最適化されていない可能性があることをユーザーに通知します（デバッグ構成でアセンブル）。 長い間、このメッセージがnugetパッケージを使用してコンテナに接続されているプロジェクトでこのメッセージが表示された理由と、nugetパックのパラメーターの可能なリストを見たときの驚きは理解できませんでした：

 nuget pack MyProject.csproj -properties Configuration=Release 

デバッグ構成でパッケージを収集していた間、更新された測定結果から判断すると、パフォーマンスが最大で25％低下したことがわかりました。

1.2.3

もう1つの最適化は、アクティベーター関数のキャッシュで、Expressionを使用してコンパイルされます。

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

汎用関数は、引数ConstructorInfoと引数ParameterInfo[]配列を受け取り、結果として厳密に型指定されたラムダを返します。

 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(); } 

この解決策の論理的な継続は、ActivatorだけでなくResolve関数全体をコンパイルすることであることに同意します

1.2.4

記事の公開後、 @ turbanoffは、 ConcurrentDictionaryの場合、 GetOrAddメソッドのパフォーマンスがContainsKey / Add ConcurrentDictionaryパフォーマンスよりも高いことにGetOrAddました。 測定結果を以下に示します。

宛先：

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

後：

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

PS

実験として、さまざまなデザインを使用してオブジェクトの作成時間を測定することにしました。 プロジェクト自体はGithubで入手でき、以下の結果を見ることができます。 完全を期すために、欠落しているのは、Directメソッドに可能な限り近いIL命令を生成するアクティベーションメソッドです。これは、トップ4のコンテナーで使用されるメソッドであり、このような印象的な結果を達成できます