[aspectj-dev] Performance of generated code

[Wes Isberg <wes@xxxxxxxxxxxxxx>]

Erik/Jim,

Would you verify and/or comment on my assumptions and questions
below about what we should expect of the runtime performance
of code produced by our 1.1 implementation?  (I obviously
could infer some from generated bytecode, but then I'd ask
you to confirm anyway...)

I realize we don't know the significance of any answer until
we have a decent benchmark suite, but this should give us
some testable assertions and form the basis for documentation
and discussion on point.

Feel free to comment more generally on what to expect.

Wes

---- assumptions
Inter-type declarations of member and parents have the same
performance characteristics as comparable hand-coded declarations.

PCD's this(), target() and args() result in runtime checks
implemented with instanceof, which has been optimized in
modern VM's.

PCD's cflow() and cflowbelow() checks are comparable to
accessing a ThreadLocal and doing a map look-up.

Implementing (non-inlined) advice adds one static call
and one dynamic dispatch for the join point, plus one dynamic
dispatch for each advice.  (It's the latter that could
be optimized away by VM inlining.)  (And considering only
join points for call, execution, get, and set.  True also
of adviceexecution?)

The additional performance overhead of after advice over
after is like that of a try-finally clause.  It's faster
to use after returning.  [true in 1.0; also in 1.1?]

Around advice has the same performance penalty as
after advice (if not inlined).

---- questions

Are instanceof checks omitted in code where they are known
to be true, e.g., this(Runnable) inside such a class?

Is there any effort to reduce the cost of evaluating a
pointcut by deferring evaluation of the costlier PCD's
(to determine that a pointcut doesn't match at less cost)?
This is the order I'd guess we'd use for performance:

  this(), target(), args(), cflow(), cflowbelow(), and if()

If one wanted to patch the compiler to make "if(false)"
staticly-determinable, what would one need to do?
Is that different from what would be required to make
"if(FALSE)" staticly-determinable, if FALSE were a
compile-time constant with the value false?

Would that also prevent the compiler from evaluating
other pointcuts combined with it using &&, and thus
save any compilation time?