when is AOP code executed

Question

I have read some articles about AOP and it looks like a very interesting and powerful tool.

But what about performance?

For example, what if I create an aspect a

Answer 1

Let's talk about performance and AOP implementations.

AOP Framework have to be carefully about 3 critical things to be faster :

• fire-time (runtime initialization)
• interception mechanic
• consumer integration

in nominal usage, only interception mechanic and consumer integration are really important unless you spam restarting your application.

Usually an AOP Framework working at compile time does not have any fire time and interception mechanic is similar as you really write the advice directly in the code. That's why they are often efficients.

Concerning runtime AOP Framework, they are often not really AOP pattern because they need proxy/factory pattern to intercept method calls. Proxy means 2 types of overhead : wrapping or message sink. In the first case it is acceptable and for the second, it really cost.

Both compile time and runtime AOP have the same issue for the consumer integration :

• boxing/unboxing
• process original code
• the way you can define your advice.

it is justified by the need to define a transversal code.

The consumer integration represents the real pitfall (performance issue) of an AOP Framework.

Compile time has often only this point to manage. That's why most of time they are better in term of performance.

I wrote "usually" because it is true for common implementations.

In absolute, runtime AOP Framework can do better because it can have more informations while weaving. It is just harder (impossible?) to implement an efficient runtime AOP Framework because it requiered a lots of undocumented knownledge to manipulate the CLR.

After a lot of research, I developed a new style of .NET runtime AOP Framework which can break the rules. NConcern .NET AOP Framework is built to be efficient (even more than compile time based) by offering an exclusive interception mechanic (based on method swaping) and consumer integration by simple delegate, expression and ILGenerator to avoid boxing/unboxing and unecessary client usage preparation. For example, most of time it is necessary to use reflection to know how to execute the advice. A lot of AOP Framework give the metadata in real treatment, that means they have an overhead by preparing it. In a good implementation (like NConcern offer), you can have these informations before the real treatment because the AOP Framework offer you to describe how to generate Advice instead of coding it directly with reflection and boxing. Even in basic interface (direct advice definition) of NConcern you have choice to capture or not the metadata.

To conclude, be carefully about client AOP interface to define your advices, it represents most of case the real performance overhead.