Was sind die "Kosten" der .NET-Reflektion?

Question

Mögliche Duplizieren:
How costly is .NET reflection?

Ich bin derzeit in einer Programmiersprache Mentalität, dass Reflexion ist mein bester Freund. Ich benutze es sehr für dynamisches Laden von Inhalten, die "losen Implementierung" statt strenge Schnittstellen, sowie eine Menge von benutzerdefinierten Attributen ermöglicht.

Was sind die "echten" Kosten für die Verwendung von Reflektion?

Lohnt es sich, häufig gespiegelte Typen im Cache zu speichern, z. B. unseren eigenen LINQ-DAL-Objektcode für alle Eigenschaften für Tabellendefinitionen?

Wäre die Speicherauslastung des Caching-Speichers größer als die Reflektions-CPU-Auslastung?

Answer 1

Reflection benötigt eine große Menge der Typ-Metadaten, die geladen und dann verarbeitet werden. Dies kann zu einem größeren Speicheraufwand und einer langsameren Ausführung führen. Gemäß this article ist die Eigenschaftsmodifikation ungefähr 2,5x-3x langsamer und der Methodenaufruf ist 3,5x-4x langsamer.

Hier ist eine hervorragende MSDN article umreißt, wie Reflektion schneller und wo der Overhead ist. Ich empfehle sehr zu lesen, wenn Sie mehr erfahren möchten.

Es gibt auch ein Element der Komplexität, das Reflektion dem Code hinzufügen kann, wodurch es wesentlich verwirrender und damit schwieriger zu bearbeiten ist. Einige Leute, wie Scott Hanselman glauben, dass durch die Verwendung von Reflektion Sie oft mehr Probleme machen, als Sie lösen. Dies ist insbesondere der Fall, wenn Ihre Teams meist Junior Devs sind.

Sie können besser in die DLR (Dynamic Language Runtime) schauen, wenn Sie viel dynamisches Verhalten benötigen. Mit den neuen Änderungen in .NET 4.0 möchten Sie vielleicht sehen, ob Sie etwas davon in Ihre Lösung integrieren können. Die zusätzliche Unterstützung für Dynamic von VB und C# macht die Verwendung von dynamischem Code sehr elegant und das Erstellen eigener dynamischer Objekte relativ einfach.

Viel Glück.

EDIT: Ich habe mehr stochern um Scott Website und fand diese podcast auf Reflexion. Ich habe es nicht gehört, aber es könnte sich lohnen.

Answer 2

Mit großer Kraft kommt große Verantwortung.

Wie Sie sagen, hat die Reflektion mit Kosten zu tun, und je nachdem wie viel Reflektion Sie tun, kann die Anwendung erheblich verlangsamt werden.

Einer der sehr geeigneten Orte, um es zu verwenden, ist für IoC (Inversion of Control), da, je nach der Größe Ihrer Anwendung, würde wahrscheinlich mehr Vorteile als nicht haben.

Answer 3

Danke für die tollen Links und tollen Kommentare, besonders seitens der Jr Devs, die es richtig auf das Geld abgesehen haben.

Für uns ist es einfacher für unsere Junior-Entwickler, dies zu tun:

[TableName("Table")] 
public class SomeDal : BaseDal 
{ 
    [FieldName("Field")] 
    public string Field 
} 

eher als einige größere impelementations von DAL.Dies beschleunigt das Erstellen der DAL-Objekte, während alle internen Vorgänge für die leitenden Entwickler verborgen bleiben.

Schade LINQ kam früher nicht heraus, ich fühle manchmal die Hälfte davon geschrieben.

Answer 4

Es gibt viele Dinge, die Sie tun können, um die Reflexion zu beschleunigen. Zum Beispiel, wenn Sie viel Eigentum-Zugang machen, dann HyperDescriptor könnte nützlich sein.

Wenn Sie viele Methoden aufrufen, können Sie Methoden für typisierte Delegaten zwischenspeichern, indem Sie Delegate.CreateDelegate verwenden - dies führt die Typüberprüfung usw. nur einmal durch (während CreateDelegate).

Wenn Sie eine Menge von Objektkonstruktion machen, dann Delegate.CreateDelegate wird nicht helfen (Sie können es nicht auf einen Konstruktor verwenden) - aber (in 3.5) Expression kann dazu verwendet werden, erneut kompilieren zu einem getippt delegieren.

Also ja: Reflexion ist langsam, aber Sie können es ohne zu viel Schmerz optimieren.

Answer 5

Eine Sache, die Sie bei der Verwendung von Reflektionen manchmal beißen kann, ist das Aktualisieren von Anrufen bei der Reflektion beim Refactoring nicht. Tools wie Resharper werden Sie auffordern, Kommentare und Strings zu aktualisieren, wenn Sie einen Methodennamen ändern, so dass Sie die meisten davon auf diese Weise abfangen können. Wenn Sie jedoch Methoden aufrufen, die dynamisch generiert wurden oder der Methodenname dynamisch generiert wurde vermisse irgendwas.

Die einzige Lösung ist eine gute Dokumentation und gründliche Komponententests.