Re: the forum, I have noticed actually that many people just hang around on stackoverflow these days. People seem to like to score points by answering questions on there so it can be a great place to get answers.
I had a look at what you sent me. Your pointcuts look fine. As you note it is the pure method ones that check for an annotation that are going to be the slowest. aop.xml file looks good too.
Re: caching, the 'usefullltw' option is what the tests used to switch on that behaviour. In your environment you should pass these two system properties to the VM:
First, switch it on:
aj.weaving.cache.enabled=true
Second, choose an implementation:
aj.weaving.cache.impl=perloader
or
aj.weaving.cache.impl=shared
The 'shared' option is faster but only works if all your classloaders that are using aspects are using the exact same aspects (This may be the case for you, so try it).
Other thoughts about speed: is the JVM tight on memory? There are some strategies employed in the weaver that involve throwing things away and recovering them again if needed (via weak/soft references). If a JVM is tight on memory this can slow things down, even though weaving is working.
Have you tried using the weaver (via -javaagent) but not actually passing in the aspect via aop.xml - is it still slow? Have you adding/removing/adjusting some of the pointcuts to see if that has an impact - maybe there is one that is really hurting things. I wonder if there are some very critical joinpoints being hit that are a bottleneck for everything. One observation on your code, your pointcut 'metricAverseMethod()' is checking for types that have '@MetricAware' on them, is that right?
You could try a code style aspect. Using code style the compiler does some extra things and may even do more advice inlining to reduce the number of closures created (which actually might get you beyond the compile time weaving problem you were seeing...)
I usually take a yourkit profile as the next stage (or try your jvm profiling tool of choice).
cheers,
Andy