We have started to use spring aop for cross cutting aspects of our application (security & caching at the moment).
My manager worries about the performance impact of this technology although he fully understands the benefits.
My question, did you encounter performance problems introduced by the use of aop (specifically spring aop)?
As long as you have control of your AOP I think it's efficient. We did have performance problems anyway, so by own reasoning we were not fully in control ;) This was mostly because it's important that anyone that writes aspects has full understanding of all the other aspects in the system and how they interrelate. If you start doing "smart" things you can outsmart yourself in a jiffy. Doing smart things in a large project with lots of people who only see small parts of the system can be very dangerous performance-wise. This advice probably applies without AOP too, but AOP lets you shoot yourself in the foot in some real elegant ways.
Spring also uses proxying for scope-manipluations and thats an area where it's easy to get undesired performance losses.
But given that you have control, the only real pain point with AOP is the effect on debugging.
If performance is going to be a concern, we have used AspectJ to great effect.
Because it uses bytecode weaving (compile time vs. runtime makes quite the difference) it's one of the fastest AOP frameworks out there. See: AOP Benchmarks
When I used it, I didn't - but then my application isn't your application.
If you use it for calls which are used in a very tight loop, there's the opportunity for a significant performance hit. If it's just used to check security once per request and cache various things, I can't see how it's likely to be significant - but that's why you should profile and benchmark your app.
I realise that "measure with your app" probably isn't the answer you were looking for, but it may well be the one you guessed you'd get :)
If you are using proxy-based AOP, you are talking about 1 additional Java method invocation per aspect applied. The performance impact there is pretty negligible. The only real concern is the creation of the proxies but this usually happens just once on application startup. The SpringSource blog has a great post on this:
http://blog.springsource.com/2007/07/19/debunking-myths-proxies-impact-performance/
In theory, if you use AOP do to what you could do with hard coupling, there is no performance issue, no overhead and no extra method calls unless you weave for nothing. AOP Framework offers you a way to remove the hard coupling and factorize your cross-cutting concern.
In practice, AOP Framework can introduce 3 types of overhead:
For more details you can refer to when-is-aop-code-executed.
Just be careful how you implement an advice because transversal code is a temptation for boxing/unboxing and reflection (expensive in term of performance).
Without an AOP Framework (hard coupling your cross-cutting concerns) you can develop your presumed advices (dedicated for each treatment) easier without boxing/unboxing and reflection.
You have to know that most AOP Framework don't offer the way to avoid totally boxing/unboxing and reflection.
I developed one to respond to most of missing needs concentrated to 3 things :
You can find my open source project here : Puresharp API .net 4.5.2+ previously NConcern .NET AOP Framework
If you are using some one framework for aspects there can be some performance issues .Next if you are creating abstraction above some one framework and aspects handling is done from framework then its very difficult to find out the cause of the problem relating to performance issues . If you are really concern about performance and small time slice concern more ,i suggest to write own aspects .No one want to reinvent the wheel but sometime for better it can be best.You can write own implementation of AOP alliance abstraction .
i have used spring AOP in a batch process in my current project to transaction manage a database.
At first, it was figured that there wouldn't be a performance problem, but we didn't figure into the equation that we called the database thousands of times. one aspect call in aop doesn't affect performance much, but multiply that by thousands, and it turns out the new system was worse than the old one, due to these extra method calls.
I'd say that aop is a great system to use, but try to take note on how many methods calls are added to your application
Have you ever thought about an AOP tools that adding aspects to object at runtime when you need? There is one for .net "Add Aspects to Object Using Dynamic Decorator" (http://www.codeproject.com/KB/architecture/aspectddecorator.aspx). I believe you can write a similiar one for Java.
11 years after the question, look how degenerated this situation is.
Example: the vast majority think it is ok and normal to put a simple @Transactional spring java annotation to some method and let spring do the bridge between caller and callee proxied components. Now they have 20+ stackframes of undebuggable 'magic' code. The JIT compiler is rapidly exceeded and can no longer attempt inlining, or ends up bloating memory with tons of generated classes.
There is no limit to lazyness in this era of 'framework users'. No wonder e2e times for trivial http calls went from 100ms to 10 seconds. No wonder you need 2GB to run a lousy servlet container that used to run in 128MB. And don't get me started on the cost of logging exception stacktraces...
