依存関係の挿入の使用によるオーバーヘッド

Question

依存関係の注入は大きなオーバーヘッドを引き起こす可能性がありますか?

特にリゾルバーが何度も呼び出される場合（パターンの例を見るとかなりの確率でそうなります）、そう想像されますか？それとも私の考えが間違っているのでしょうか？残念ながら、使用したことはありませんが、使用する予定があるため、自分でテストすることはできません。

Answer 1

サービスロケーターを使用していない限り、オーバーヘッドが大きな違いをもたらします。 （たとえあなたがそうであっても、それは重要ではないでしょう。）

コンストラクター注入と最新のフレームワークを使用して、リゾルバーはオブジェクトが構築されるときに呼び出されます。ほとんどの場合、依存関係のあるオブジェクトは、比較的高レベルのコンポーネントであるか、長期間有効であるか、またはその両方であることがわかります。

IoCコンテナを使用し、緊密なループ内で依存関係を持つオブジェクトの多くを作成している場合、いくつかの最適化を行う必要がある場合があります。いつでもプロファイルまたはベンチマークを実行できます。

要するに、私はそれについて心配しません。

Answer 2

概念としての依存性注入は高いオーバーヘッドを必要としない。それは単にコードをハードワイヤードするのではなく、実行時に他のクラスへの接続を構築できるようにクラスを構築するだけである。

もちろん、オーバーヘッドが大きい可能性のあるランタイム接続を構築する方法があります。これらの方法は避けてください。

Answer 3

http://www.codinginstinct.com/2008/04/ioc-container-benchmark-unity-windsor.html パフォーマンステスト用。各テストでは 1000,000 個の作成が実行されました。

ベンチマークはシングルトン解像度と一時解像度を示していることに注意してください。シングルトンとは、クラスのインスタンスを登録するものです。(Unityを使用):

container.RegisterInstance<IMyType>(new ConcreteMyType());

このインスタンスは毎回返されます (これは非常に高速です)。

トランジェントとは、クラス タイプだけを登録すると、IoC フレームワークがそれを作成する仕事をします。(Unityで)

container.RegisterType<IMyType, ConcreteMyType>();

これには、シングルトンを返すよりも時間がかかります。

全体的な最適化の観点から見ると、依存関係の注入のオーバーヘッドはわずかです。他のパフォーマンスのボトルネックが最適化される可能性が高くなります。

Answer 4

依存性注入それ自体は単なる間接的なものであるため、オーバーヘッドはありますが、実際には非常に小さなものです。実行時のパターンマッチングと解決は別のことです（ただし、Dependency Injectionでよく使用されますが、DIがそのような余分なものを要求するようではありません;-）。

Answer 5

依存性注入は大きなオーバーヘッドを与えません。他のどこかでボトルネックが見つかると確信しています。オーバーヘッドが非常に心配な場合は、C＃は使用したい言語ではないかもしれません。 C＃を使用する利点は、C＃がもたらす利点であり、対処したくない詳細を抽象化します。

DIでも同じですが、アプリケーションを疎結合にするなどの利点もあります。これは、今後のメンテナンスが容易になることを意味します。

Answer 6

オーバーヘッドとテスト可能かつ保守可能なコード...テスト可能かつ保守可能なコードを選択します（より高速なコンピューターをいつでも購入できます）

=）