diff options
author | wisberg <wisberg> | 2003-08-23 15:05:00 +0000 |
---|---|---|
committer | wisberg <wisberg> | 2003-08-23 15:05:00 +0000 |
commit | 359f247dc87c44668970dd550e43dc777cdb4a27 (patch) | |
tree | 1efe21af643e77e1661567e4aac10e044f0fe8b8 /docs/faq | |
parent | 31f9de4724c8c794527275aa3dccf07c0e362d77 (diff) | |
download | aspectj-359f247dc87c44668970dd550e43dc777cdb4a27.tar.gz aspectj-359f247dc87c44668970dd550e43dc777cdb4a27.zip |
performance faq item corrections promised on the list.
I need some actual facts for a real answer.
Diffstat (limited to 'docs/faq')
-rw-r--r-- | docs/faq/faq.xml | 28 |
1 files changed, 17 insertions, 11 deletions
diff --git a/docs/faq/faq.xml b/docs/faq/faq.xml index 539f89edc..b1b65d05c 100644 --- a/docs/faq/faq.xml +++ b/docs/faq/faq.xml @@ -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> |