リフレクション：リフレクションの使用は、まだ「悪い」または「遅い」ですか？2002年以降、リフレクションで何が変わったのですか？

式または式ツリーを扱うとき、プロパティの値を設定および取得するためにリフレクションをたくさん使用していることに気付きました。リフレクションの使用がますます一般的になっているように思われました。検証用のDataAnotations、Attribute Heavy ORMなど。

それで、もし何か変わったとしたら？機械の速度だけですか？リフレクションを高速化するためにフレームワークに変更がありましたか？

それとも実際に何も変わっていませんか？リフレクションを使用するのはまだ「悪い」ですか「遅い」ですか？

反射は悪くも遅くもない。これは単なるツールです。すべてのツールと同様に、特定のシナリオでは非常に価値があり、他のシナリオではそれほど価値がありません。

パフォーマンスが本当に問題になる場合は、常にFasterFlectなどのライブラリを使用できます。

さらなる参考
文献反射が非効率的な場合、いつ最適ですか？

人々が不必要にリフレクションを使用することを警戒する理由はパフォーマンスではありません：はい、リフレクションを使用するためのオーバーヘッドがありますが、多くの場合、問題を解決せずに解決するには、同等の複雑さを持つ別のアプローチが必要です。あまり重要ではありません（特にアプリケーションレベルの開発）。

リフレクションを使用すると、ソースコードに関して通常行うことができるいくつかの重要な仮定が破られ、「すべての参照を検索する」などのツールが確実に機能しなくなります。また、リフレクションは、コンパイラがC＃などで実施するほとんどのタイプセーフを基本的に削除し、タイプシステムが通常キャッチしてコンパイラエラーに変換するプログラミングエラーのほとんどを除去します。

では、なぜ人々は反射を使用するのでしょうか？簡単に言えば、上記の問題にもかかわらず、非常に貴重なツールだからです。リフレクションを使用すると、動的プログラミングの利点の一部がC＃などの静的で厳密に型指定された言語で得られ、動的プログラミング言語は最近、特にWebプログラミングの領域（PHP、Javascript、非常に顕著なPython）でメリットを発揮します、すべてが動的型付けを使用し、Webプログラミングに適していることが証明されています。しかし、言語はまだC＃で​​あるため、アプリケーションのほとんどを厳密に型指定されたOOPイディオムに保ち、動的な振る舞いがリフレクションと実際に違いを生じる小さな部分を記述することを選択できます。

典型的な例は、メソッドをWebサービス呼び出しとして公開する必要がある場合です（まだ.NETに組み込まれていないプロトコルを使用）。厳密に型指定されたOOPアプローチは機能しますが、制限が厳しく、扱いにくいです。ただし、リフレクションを使用してメソッドの呼び出しとキー/値のペアを引数にマッピングする場合、そのようなWebサービスの配管を一度記述してから、任意のクラスで使用できます。

リフレクションは、直接呼び出しよりもかなり遅くなります。次の2つのことが変更されました。

• ランタイムはリフレクションメカニズムを最適化しているため、差は小さくなっています。
• CPUが高速になったため、小さな非効率性が許容されやすくなりました

これらの2つの要因により、リフレクションのコストが日常的に使用できるポイント（保守性POVから適切な場合）まで引き下げられ、プロファイラーが実際にボトルネックであるかどうかを確認するまで待機します（そして、そうではない時）。