(Warum) Ist Reflection in .Net so teuer?

Question

Mögliche Duplizieren:
What is the “cost” of reflection?

Hat jemand eine gute Erklärung für die allgemein anerkannten Mantra haben, dass reflection == bad performance?

Zum Beispiel, wie teuer ist es, die Eigenschaftensammlung eines Typs zu durchlaufen und alle Eigenschaftswerte aus einer Instanz dieses Typs zu extrahieren, verglichen mit dem direkten Zugriff auf alle Eigenschaften? Eine Größenordnung? Zwei? Wovon hängt es ab? Ist es überhaupt vorhersehbar? Was passiert unter der Haube?

EDIT: Danke für die Antworten bisher. Ich habe mir einige der Links angesehen, die Sie zur Verfügung gestellt haben, und es scheint, dass es eine große Lücke an Schätzungen bezüglich Reflection on Properties im Vergleich zum direkten Zugriff gibt: von 2,5 mal langsamer bis 200 mal langsamer.

Das scheint mir nicht sehr sinnvoll. Einige von Ihnen erwähnten Leistungsverbesserungen in späteren Versionen von .Net. Lassen Sie mich daher meine Frage auf .Net 4.0 beschränken. Hat jemand irgendwelche Benchmarks dafür?

Answer 1

Wen kümmert es, was andere Leute denken? Wenn Sie eine fundierte Untersuchung Ihrer Optionen durchgeführt haben (einschließlich anderer Ansätze, bei denen die von Ihnen untersuchte Technik nicht erforderlich ist) und diese als die richtige Option gefunden haben, verwenden Sie sie.

http://www.parashift.com/c++-faq-lite/big-picture.html#faq-6.16

Wie bei „was unter der Haube vor sich geht,“ Sie scheinen ein Teil des Bildes zu haben. Es gibt auch die Tatsache, dass keine der Verknüpfungen fest codiert ist, alles muss zur Laufzeit nachgeschlagen werden. Dies bedeutet, dass keine In-Lining möglich ist, keine Compiler-Fehler erzeugt werden, wenn Sie einen Mitgliedsnamen falsch eingeben, und alle Mitglieder müssen nach einer Zeichenfolge gesucht werden, wobei alle zugehörigen Zeichenfolgen Perf-Hits vergleichen (die möglicherweise vorhanden sind oder nicht) wie String Interning, etc).

Edit:

Nun, ich denke, das letzte Teil meiner Antwort ist nicht unbedingt richtig. Es hängt weitgehend davon ab, wie Sie Reflexionen verwenden. Profil! Und wenn Sie eine alternative Lösung finden, profilieren Sie das auch. :)

Answer 2

Es gibt einige Fragen zu SO, die dies auf verschiedene Arten beantworten.

Hier ist ein guter IMO: What is the "cost" of .NET reflection?

Einer der articles the answerer links gibt einige interessante Informationen über bestimmte Funktionen der Reflexion ist teurer als andere. Zum Beispiel ist es nicht so schlimm, einen Typ zu machen, aber das Aufrufen von Methoden ist kostspieliger.

Answer 3

Die beste Antwort ist, dass das allgemein akzeptierte Mantra nicht so einfach ist wie es scheint. reflection == bad performance stammt weitgehend von .NET 1.0 und 1.1 und erkennt die Leistungsverbesserungen in späteren Versionen nicht an.

Um objektiv zu sein Ich habe mehrfach reflexionsbasierte Lösungen im Vergleich zu nichtreflektierenden Lösungen getestet - und der Gewinner ist nicht immer der eine oder der andere.Reflexion ist was es ist und es funktioniert, wie es funktioniert, es ist nicht konstant schneller oder langsamer und es kann (wie bei allen Programmieransätzen) nicht als eine Silberkugel behandelt werden oder als etwas, das immer vermieden werden sollte.

Answer 4

Es gibt eine Menge Missverständnisse bezüglich der Reflexion.

This guy hat gezeigt, dass eine Reflexion etwa 3 mal länger dauert als eine direkte Zuweisung. In der Praxis würde diese Funktion, die ordnungsgemäß verwendet wird, keinen spürbaren Einfluss auf die Leistung haben. Es ist nichts falsch daran, Reflexionen im richtigen Kontext zu verwenden.

Answer 5

Es gibt einige Dinge, die Sie mit statisch nicht tun können. Verwenden Sie Reflexion, wenn Sie sie brauchen. Sie benutzen es wahrscheinlich schon öfter, als Sie wissen.

Ich habe viele Leistungstests und Messungen für Reflexion vs statische Operationen durchgeführt. Reflexion hat mehr zu tun und ist immer langsamer. Aber das ist OK. "Langsamer" bedeutet nicht "langsam", sondern nur "nicht so schnell". So sollte es betrachtet werden. Die Reflexion kann immer noch schnell sein, nur nicht so schnell wie eine statische Operation. Es sollte deshalb nicht automatisch gemieden werden.

Ich habe für Lead-Entwickler gearbeitet, die absolut keinen reflektierenden Code in einem Web-Projekt verboten haben, weil es langsam wäre. Aber es kam ihm nie in den Sinn, dass wir NHibernate, ASP.NET und ASP.NET MVC Data Binding verwenden, die fast ausschließlich mit reflektiven Datenbindungen arbeiten.

Die Abneigung dieser Person gegenüber der Reflexion war irrational und unbegründet. Ich denke, das ist bei vielen Leuten der Fall, mit denen man darüber spricht.