AOP overhead

Question

I was looking a bit for some performance tests for typical AOP tasks. I couldn’t find anything, could you help me? I mainly think of Castle, Unity, and possibly PostSharp, although it might be too expensive for my project.

Answer 1

I have not seen quantitative comparisons either, so this answer is probably far from complete.

It is difficult to compare the performance of Castle or Unity with PostSharp - Castle and Unity, using runtime weaving using dynamic proxying, and PostSharp adds overhead at compile time . Therefore, if performance is important to you, compiled solutions like PostSharp will always be better. Generating AOP proxies at runtime means dynamically generating IL code and intense reflection.

Thus, performance tests that might make sense should compare solutions using the same method - you can try comparing the implementation of the Castle Dynamic Proxy and Unity Interception proxies.

I don’t know the first, but in the latter case there are three different scenarios for comparison: transparent proxies ( MarshalByRefObject ), proxies and subclassing proxies, each with its own set of usage scenarios and its own operational overhead. From what I read, the transparent proxy is terribly slow and should not be used in AOP scripts. The proxy interfaces and subtypes generate some IL on the fly, and this is the same thing as the DP lock does, so I believe that the differences should not be so big (but again, there are no quantitative results).

Answer 2

If you are looking for a lightweight AOP tool, there is an article entitled “Add Aspects for an Object Using a Dynamic Decorator” (http://www.codeproject.com/KB/architecture/aspectddecorator.aspx). It is slim and flexible.

It describes the approach of adding aspects to an object at runtime, rather than adding aspects to a class at design time. The advantage of this approach is that you decide if you need an aspect when using the object.

Most modern AOP tools define class-level aspects during class development. And you do not have the flexibility to use the class object.

Answer 3

If the performance of your project is complex, make sure that using AOP is performance-oriented, as the overhead of the AOP Framework is rarely poor if the use is inadequate.

For example, if you use DynamicProxy, you have the choice to invoke reverse processing using reflection or invoke the Proceed () method. This changes different performance.

Another example: most AOP Framework provide you with MethodInfo for your "advice". The way they get this metadata can change your performance, because GetMethodFromHandle can be very bad in extremely concurrency treatment (access to a dictionary with blocking).

Another important thing to keep in mind: use the adapted overlap method for the Advice method, because if the AOP Framework needs to prepare too much information (argument, method info, ...), you will pay (overhead). Unfortunately, sometimes there is no good user interface for implementing an executive board if the interception was perfect.

For more information, in the when-is-aop-code-executed message, I will talk about performance issues with the AOP Framework.