Ich habe auch keine quantitativen Vergleiche gesehen, daher ist diese Antwort wahrscheinlich noch lange nicht vollständig.
Es ist schwierig, die Leistung von Castle oder Unity mit PostSharp zu vergleichen - Castle and Unity verwenden Laufzeitweben durch dynamisches Proxying und PostSharp fügt Overhead beim Kompilieren hinzu . Wenn Leistung für Sie von entscheidender Bedeutung ist, werden kompilierte Lösungen wie PostSharp immer besser. Generieren von AOP-Proxies in Runtime bedeutet dynamisches Erzeugen von IL-Code und starker Reflektion.
Daher können Leistungstests, die Sinn ergeben, Lösungen mit der gleichen Technik vergleichen. Sie können versuchen, Castle Dynamic Proxy und Unity Interception Proxy-Implementierung zu vergleichen.
Ich kenne das erstere nicht gut, aber im Fall von letzterem gibt es immer noch drei verschiedene Szenarien zum Vergleichen - transparente Proxies ( MarshalByRefObject ), Interface-Proxies und Subklassen-Proxies - jeweils mit eigenen Nutzungsszenarien und seine eigenen Leistungsgemeinkosten. Von dem, was ich gelesen habe, ist der transparente Proxy schrecklich langsam und sollte nicht in AOP-Szenarien verwendet werden. Interface und Subtyping-Proxies erzeugen etwas IL on the fly und das ist das selbe, was Castle DP tut, also glaube ich, dass die Unterschiede nicht so groß sein sollten ( aber auch hier keine quantitativen Ergebnisse)
Wenn Sie nach einem leichten AOP-Werkzeug suchen, gibt es einen Artikel "Hinzufügen von Aspekten zum Objekt mit Dynamic Decorator" (http://www.codeproject.com/KB/architecture/aspectddecorator.aspx). Es ist dünn und flexibel.
Es beschreibt einen Ansatz zum Hinzufügen von Aspekten zum Objekt zur Laufzeit, anstatt zur Entwicklungszeit Aspekte zur Klasse hinzuzufügen. Der Vorteil dieses Ansatzes besteht darin, dass Sie entscheiden, ob Sie beim Verwenden eines Objekts einen Aspekt benötigen.
Die meisten AOP-Tools von heute definieren Aspekte auf Klassenebene zur Zeit des Klassenentwurfs. Und Sie haben nicht die Flexibilität, wenn Sie ein Objekt der Klassen verwenden.
Wenn die Leistung in Ihrem Projekt entscheidend ist, stellen Sie sicher, dass Ihre Verwendung des AOP leistungsorientiert ist, da der Aufwand eines AOP-Frameworks selten schlecht ist, es sei denn, die Verwendung ist nicht konform.
Wenn Sie beispielsweise DynamicProxy verwenden, haben Sie die Wahl, die Backing-Behandlung über Reflection aufzurufen oder die Methode Proceed () aufzurufen. Es verändert die Leistung unterschiedlich.
Ein anderes Beispiel: Die meisten AOP Framework geben Ihnen die MethodInfo zu Ihrem "Rat". Die Art und Weise, wie sie diese Metadaten erhalten, kann Ihre Leistung beeinträchtigen, da GetMethodFromHandle in extrem nebenläufigen Behandlungen (Wörterbuchzugriff mit einer Sperre) sehr schlecht sein kann.
Eine weitere wichtige Sache, die Sie beachten sollten: Verwenden Sie das angepasste Overlod für Advice-Methode, denn wenn AOP Framework zu viele Informationen vorbereiten muss (Argument, methodinfo, ...), zahlen Sie es (Performance Overhead). Unglücklicherweise gibt es manchmal keine gute Benutzerendschnittstelle, um ein performantes Beratungsereignis zu implementieren, wenn die Überwachung perfekt war.
Weitere Einzelheiten finden Sie im Beitrag when-is-aop-code- ausgeführt , gebe ich mein Feedback zum Leistungsproblem von AOP Framework.