AOP performance overhead

I've been searching a bit for some performanc开发者_如何转开发e tests about typical AOP tasks. I've not been able to find any though, could you help me? I'm mostly thinking about Castle, Unity and perhaps PostSharp, even though it might be too expensive for my project.

I haven't seen any quantitative comparisons, too, so this answer is probably far from being complete.

It is difficult to compare performance of Castle or Unity with PostSharp - Castle and Unity use runtime weaving by dynamic proxying and PostSharp adds overhead at compile stage. So if performance is crucial for you, compiled solutions like PostSharp will always be better. Generating AOP proxies in runtime means dynamic generating IL code and heavy reflection use.

So performance tests that could make sense have to compare solutions using the same technique - you can try to compare Castle Dynamic Proxy and Unity Interception proxy implementation.

I don't know the former well, but in case of latter, there are still three different scenarios to compare - transparent proxies (MarshalByRefObject), interface proxies and subclassing proxies - each with its own set of usage scenarios and its own performance overheads. From what I've read, transparent proxy is horribly slow and shouldn't be used in AOP scenarios. Interface and subtyping proxies generates some IL on the fly and this is the same what Castle DP does so I believe the differences shouldn't be so big (but again, no quantitative results here).

If you are looking for a light weight AOP tool, there is a article "Add Aspects to Object Using Dynamic Decorator" (http://www.codeproject.com/KB/architecture/aspectddecorator.aspx). It is thin and flexible.

It describes an approach to adding aspects to object at runtime instead of adding aspects to class at design time. The advantage of this approach is that you decide if you need an aspect when you use an object.

Most of today's AOP tools define aspects at class level at class design time. And you don't have the flexibility when you use an object of the classes.

If performance is crutial in your project, make sure your usage of the AOP is performance oriented because the overhead of an AOP Framework is rarely poor unless the usage is not compliant.

For example, if you use DynamicProxy, you have the choice to call the backing treatment using reflection or calling Proceed() method. It alter differently performance.

Another example : most of AOP Framework give you the MethodInfo to your "advice". The way how they get this metedata can alter your performance because GetMethodFromHandle can be very bad in extremely concurrency treatments (dictionary access with a lock).

Another important thing to keep in mind : use the adapted overlod for Advice method because if AOP Framework have to prepare too much informations (argument, methodinfo, ...) You will pay it (performance overhead). Unfortunely, sometimes there is no good user end interface to implement a performant advice event if interception was perfect.

For more details, in the post when-is-aop-code-executed, I give my feedback about performance issue of AOP Framework.