|
|
@@ -1032,28 +1032,32 @@ aspect. |
|
|
|
important as knowing how to measure it, and neither is always |
|
|
|
apparent. |
|
|
|
</para> |
|
|
|
<para>We aim for the performance of our implementation of AspectJ to |
|
|
|
be on par with the same functionality hand-coded in Java. Anything |
|
|
|
significantly less should be considered a bug. |
|
|
|
</para> |
|
|
|
<para>There is currently no benchmark suite for AOP languages in |
|
|
|
general nor for AspectJ in particular. It is probably too early to |
|
|
|
general or for AspectJ in particular. It is probably too early to |
|
|
|
develop such a suite because AspectJ needs more maturation of the |
|
|
|
language and the coding styles first. Coding styles really drive |
|
|
|
the development of the benchmark suites since they suggest what is |
|
|
|
important to measure. |
|
|
|
</para> |
|
|
|
<para>In the absence of a benchmark suite, AspectJ probably has an |
|
|
|
acceptable performance for everything except non-static advice. |
|
|
|
Introductions and static advice should have extremely small |
|
|
|
performance overheads compared to the same functionality |
|
|
|
implemented by hand. |
|
|
|
<para>Though we cannot show it without a benchmark suite, we believe |
|
|
|
that code generated by AspectJ has negligible performance overhead. |
|
|
|
Inter-type member and parent introductions should have very little |
|
|
|
overhead, and advice should only have some indirection which |
|
|
|
could be optimized away by modern VM's. |
|
|
|
</para> |
|
|
|
<para>The <literal>ajc</literal> compiler will use static typing information |
|
|
|
to only insert those checks that are absolutely necessary. Unless you use |
|
|
|
'thisJoinPoint' or 'if', then the only dynamic checks that will be |
|
|
|
inserted by ajc will be 'instanceof' checks which are generally quite fast. |
|
|
|
to only insert the advice and dynamic pointcut tests that are absolutely necessary. |
|
|
|
Unless you use 'thisJoinPoint' or 'if', the main dynamic checks will be |
|
|
|
'instanceof' checks which are generally quite fast. |
|
|
|
These checks will only be inserted when they can not be inferred from |
|
|
|
the static type information. |
|
|
|
</para> |
|
|
|
<para>If you'd like to measure the performance be sure to write code |
|
|
|
fragments in AspectJ and compare them to the performance of the |
|
|
|
<para>When measuring performance, write AspectJ code |
|
|
|
fragments and compare them to the performance of the |
|
|
|
corresponding code written without AspectJ. For example, don't |
|
|
|
compare a method with before/after advice that grabs a lock to just |
|
|
|
the method. That would be comparing apples and oranges. Also be |
|
|
@@ -4139,6 +4143,7 @@ vmparam -Xmx384m |
|
|
|
more 1.1-driven changes and updated some process and build questions. |
|
|
|
Entries changed since the earlier June, 2003 version: |
|
|
|
<itemizedlist> |
|
|
|
|
|
|
|
<listitem><para><xref linkend="q:support"/></para></listitem> |
|
|
|
<listitem><para><xref linkend="q:mailingLists"/></para></listitem> |
|
|
|
<listitem><para><xref linkend="q:requiredsources"/></para></listitem> |
|
|
@@ -4150,6 +4155,7 @@ vmparam -Xmx384m |
|
|
|
<listitem><para><xref linkend="q:schedule"/></para></listitem> |
|
|
|
<listitem><para><xref linkend="q:incrementalModuleCompiles"/></para></listitem> |
|
|
|
<listitem><para><xref linkend="q:stepwiseBuilds"/></para></listitem> |
|
|
|
<listitem><para><xref linkend="q:effectonperformance"/></para></listitem> |
|
|
|
</itemizedlist> |
|
|
|
</para> |
|
|
|
</answer> |