Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [aspectj-dev] weaving performance

Hi Jim!

While I am happy to use my weaving class loader for a special project I
observed some performance issues relevant to my project. My simple
question is: Do you have any ideas how to improve the performance of the
weaving? I already killed the major performance bottleneck
(assertGoodBody) which improves the speed by a factor of 2. But I am
still looking for additional improvements because the startup time of my
system using the weaver is still at least five times slower and consumes
3 times as much memory than without weaving (loading 1872 classes from
89 jar-files). Any ideas?

There are certainly many low-level improvements possible to the performance of the bytecode weaver.  Erik might be able to suggest some likely places to look at.  However, unless you're actually weaving some code into most of those 1872 classes, the greatest performance gain is likely to come from implementing fast match for advice and introductions.  For every class that you can quickly determine no advice could possibly apply to without going through the expensive weaving process you will save a huge amount of time.

Implementing fast match is the most important performance issue on my todo list, but I'm unsure whether or not it will make the cut for 1.1 -- issues of correctness currently dominate issues of performance.  If you want to experiment with fast match, I'd suggest adding a new fastMatch method to org.aspectj.weaver.patterns.Pointcut that takes some wrapper around a JavaClass object and returns a FuzzyBoolean indicating whether or not there's a potential match in this class to that pointcut.

One nice thing about implementing a fastMatch routine is that it only needs to be correct and not complete.  All you need for correctness is for everyone to return FuzzyBoolean.MAYBE all the time.  If you then implement AndPointcut and WithinPointcut in the obvious ways you might see major performance gains for aspects that always use within, i.e. call(* *(..)) && within(my.package..*).  Through successive approximations this fastMatch could steadily get better.


Thanks for this advice. I implemented a first version of the fastmatch methods (in BcelWeaver and the mentioned pointcut classes) and I archieved the required performance improvements I need for my project (as long as I use within in the aspect). Great and thanks again. Any aadditional performance improvements are still highly welcome because if I am not using within inside the aspect the weaver falls back into the old performance problems, but the first step is done. :-)

-Martin

P.S.: The code changes are attached to bug no. 32457.





Back to the top