For what
it’s worth, we also mix
build-time and load-time weaving with Glassbox. To gain performance
with
load-time weaving we:
1. Guard
pointcuts using within(TypePattern+)
&& … - this lets AspectJ do fast matching. This is a big gain
if
many classes do not need to be woven.
2. Use
<weaver><include within=”TypePattern+”/></weaver>
in the aop.xml file to consistently hoist the fast matching (it’s
surprising that this gains performance over #1 but it definitely does …
at
some point I hope to investigate why this happens).
3. Exclude
weaving into statically woven
Glassbox code using <weaver><exclude within=”…”/>…,
primarily to avoid exposing a large number of internal aspects that
need to be
potentially woven against external code. We started doing this before
–outxml
was available for maintainability reasons and also before using the
first two
approaches, so hopefully we could stop doing this and still achieve
good
performance.
4. Exclude
weaving into known sets of code
where our aspects don’t apply (server internals) also using exclude
Naturally, I
would like if none of the
above were needed: if fast matching would handle #1, we didn’t need any
additional
hints in the aop.xml file from #2 and probably #3 is already a minor
performance gain. But if you want to see a real world example of
minimizing start-up
overhead with AspectJ LTW, it’s worth looking at how we do this.