[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [aspectj-dev] weaving performance
|
Martin Lippert wrote:
> 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.
-Jim
