Wednesday, March 24, 2004

Aspects can be slow

Measuring the Dynamic Behaviour of AspectJ Programs "The conventional wisdom that AspectJ does not introduce overheads seems to be explained by typical aspect usage. First, advice generally applies to user code, yet typical Java programs spend most of their time in library calls. As a percentage of the total execution time, the cost of advice is therefore insignificant in such applications. The Tetris benchmark illustrates this phenomenon. Some of our benchmarks (in particular DCM) show the opposite behaviour,where the advice is so expensive that the overheads of applying it are dwarfed."

"Contrary to popular belief, we did however also find significant overheads. This has led to the following guidelines for AspectJ usage, as well as promising areas for future compiler research:

* Loose pointcuts. It is easy to write a pointcut that matches too many join points...

* Advice that is too generic. When using the very generic form of around, this causes a significant amount of boxing and unboxing to convert arguments to the right form...

* Unwarranted use of around. Because of the above, it is generally preferable to eschew around in favour of after returning when possible...

* Pertarget. The use of per clauses to control aspect creation carries a non-negligible overhead..."
Post a Comment