Performance issues with aop for .net project

Question

I relate to the performance impact with PostSharp and Spring.NET in a large .net project (about half a million active users).

Basically, I want something like this: I don’t want to generate a log for half a million times when I create a user report. But when a user uses the system, I want to register some of his actions. Most AOP tools simply do not have this flexibility.

Is there a way to bind aspects to individual objects? Or enable or disable aspect at runtime?

Answer 1

AOP logging issues The overhead of performance for logging depends on how this is done.

I assume that you want you to enter a registration code into it. dynamic aop is only possible

• for virtual methods and
• for interfaces.

So you need compiletime aop .

I don't know how post-sharp does aop. with compiletime linfu-aop, each method gets pre-and post-execution when dynamiclally determines if and what aop aspects are executed. this trick really removes delimiters on non-virtual methods, making them pseudo-virtual.

I prefer to do manuall (= non-aop -) logging with common.logging , which uses the log4.net provider. This solution has minimal runtime if registration is disabled . Enabling / disabling logging can be done without recompiling - it is just a configuration file that can say "all datalayer actions with sql", but not "sql in the xyz module".

The expensive stacktrace analysis (which class am I logging into or for me in debug / trace, Info, ....) is performed only once for each class.

Disabled registrations can be redirected to one cheap boolen variable, plus one if. This speed to optimize size can be handled using

logger.Debug(m => m("... costly string formatting ")); 

syntax

which compiled into something similar to

 if (logger.IsDebugEnabled) call anonymous method that does the expensive string formatting 

Answer 2

My understanding for PostSharp and Spring.NET is that you define your aspects, points, etc. for its class during development. There is not much that you can do when using a class object in terms of turning aspects on or off, or changing points, etc.

You get what you defined during class development. Regardless of whether you use a single object or a million class objects. You must be very careful to use them. Otherwise, you can shoot in the foot.

What you really need is an AOP tool that addresses aspects at the object level instead of class level. There is an article Add Aspects of an Object Using Dynamic Decorator .

For me, Aspects are system requirements. System requirements are operational requirements and are best considered at the facility level at run time when the facilities are used.

Honestly, I don’t understand why most AOP tools try to solve class-level system requirements during development. This may explain why their adoption is still so limited after so many years.

Answer 3

The performance of PostSharp and Spring.NET cannot be discussed together. PostSharp uses compilation in time and Spring.NET uses weaving at runtime. This means that PostSharp adds AOP overhead only at compile time and Spring.NET only at run time - read the articles from SharpCrafters for more information.

On attaching aspects, one of the key features of AOP is pointcut. Pointcuts can be thought of as predicates that choose whether to include an aspect for a given type / method, etc. Therefore, you can always create a type structure and pointcuts to use the logging aspect only at certain points in your system - this is exactly how AOP works.

About turning on / off aspects at runtime - for PostSharp, which is compiled into your code, I believe this is not possible without any tricks. For Spring.NET, it will be easier, but still I see no reason why you need it.

Answer 4

I am actively working on the NConcern.NET AOP Framework , a new open source project with good performance. This AOP Framework runtime can enter non-virtual method code (static is enabled) and can be attached or detached at runtime.

Most existing AOP platforms rely on the same interception techniques.

• Proxy (decorator with reflection) or ContextBoundObject / RemotingRealProxy to implement runtime
• Rewriting IL on post compilation to compile AOP Framework.

That's why this is an easy way to conclude the limitations and possibilities of implementing Runtime vs Compile-Time.

However, this is not lethality, and the AOP Framework can be implemented using exclusive injection technology and a modern consumer API to be very easy to use and effective.

My implementation work is at runtime and has only a few limitations, keeping a very low connection and offering a built-in expression tree to determine how to maintain maximum performance while avoiding the reflected overhead.

Please take a look, I'm interested in your opinion on this issue. It can help me improve the product.