Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [aspectj-users] Runtime impact

Hi Guy

Guy Korland wrote:
> Is there an option to avoid the need to include "aspectjrt.jar" by using
> only a subset of the AspectJ options?  e.g. using only compile time
> joint point.

Even simple compile-time advices will require some parts of the runtime,
like exceptions and the AroundClosure. The only way to avoid the jar would
be to include it into an aggregate application jar. This can of course
create problems if some user has a different version on the classpath,
unless you re-write the namespace of your included version as well.

> Also, where can I find performance impact analysis for each type of join
> point?

Some time ago I made a small micro-benchmark and at least simple
before/after/around advices were literally irrelevant - they all amount to
a simple if-then or additional (mostly static) method call, and I wouldn't
be surprised if Hotspot (especially -server) would just eat them away,
unless the method body becomes too large to be dynamically inlined. This
is pretty much the only thing that can change and adversely affect any hot
code paths.

perthis is obviously most important for memory footprint since it needs to
create a temporary state holder for every advised instance, and
cflow/cflowbelow inspect the stack so that is probably not a good idea to
have on a hot path either.

I didn't measure the impact of the automatic autoboxing/value conversion;
not sure if the current runtime has a cache like JDK 1.5 Integer.valueOf()
does.

Unfortunately I don't have the benchmark suite any more - sorry. :(

Long story short, IMHO just using AspectJ for structuring a code base
(i.e. static advising/enabling features etc.) is pretty much irrelevant if
your app does any kind of I/O. After all, if you were to include a certain
feature manually, it would run too.

hope this helps

Holger


Back to the top