Re: Efficiency question about "if()" in PCDs: (was Re: [aspectj-dev] Reg

[Adrian Colyer <adrian.colyer@xxxxxxxxx>]

Putting the test in the if PCD itself gives better performance in some
cases, and never gives worse performance.

The reason is that entering the body of advice requires us to build a
thisJoinPoint object if the advice needs it (advice that only uses the
static part of thisJoinPoint does require this object creation).
Putting the if test in the PCD means that the advice is never called
at all if the test fails (and hence the join point object is not
built).  You need to use the -XlazyTjp flag at the moment to take
advantage of this, but we plan on switching the compiler to make
lazyTjp be the default before 1.5 final.

On 18/07/05, Dean Wampler <dean@xxxxxxxxxxxxxxxxxxxxx> wrote:
> Adrian and Cohorts,
> 
> A follow up question on efficiency; if you're going to use an "if" test
> that could either appear in the scope of a PCD or within an advice
> block, are there rules of thumb for which is better for compilation and
> runtime performance? (Of course, we shouldn't overlook the
> "documentation" value of having it in the PCD....)
> 
> For example,
> 
> before(): myPCD() && if (someStaticConditionIsTrue()) {
>    ...
> }
> 
> vs.
> 
> before(): myPCD() {
>    if (someStaticConditionIsTrue()) {
>      ...
>    }
> }
> 
> Thanks,
> dean
> 
> Adrian Colyer wrote:
> >
> > The pattern matching in AspectJ's pointcut language was deliberately
> > designed not to support regular expressions (too complex and brittle),
> > but only very simple patterns (just * in identifiers). "Programming by
> > regular expressions" is an oft-heard criticism of AOP that I would not
> > be keen to encourage. That part of the language design was settled long
> > before I came on board, and I'm sure Gregor could do a better job than I
> > of explaining the background reasoning that led to that decision. That
> > said, your own example set in context:
> >
> > before() : set(* \(*\).\(*\)) && if(exists(* $2.prefix$3(..)) {
> >   ...
> > }
> >
> > does a pretty good job of arguing the case against all on its own to my
> > aesthetic! ;)
> >
> > The (non-pattern) version of exists can be written today - I suspect a
> > signature along the lines of:
> >
> > static boolean exists(JoinPoint.StaticPart,String memberPattern)
> >
> > would enable you to do most of what you need - heck, memberPattern can
> > even be interpreted using a regex lib if you need it :)
> >
> > Then you'd write:
> >
> > before() : set( ..... ) && if(exists(thisJoinPointStaticPart,"set*(Foo)" {
> >
> > }
> >
> > or similar. It's a runtime test of course, so won't work with declare eow.
> >
> > For the common case of hasMethod and hasField, these *type patterns*
> > have been discussed on the list in an earlier thread, summarized in
> > enhancement request https://bugs.eclipse.org/bugs/show_bug.cgi?id=86818
> >
> > -- Adrian
> > Adrian_Colyer@xxxxxxxxxx
> >
> >
> > *Dean Wampler <dean@xxxxxxxxxxxxxxxxxxxxx>*
> > Sent by: aspectj-dev-bounces@xxxxxxxxxxx
> >
> > 11/07/2005 16:54
> > Please respond to
> > AspectJ developer discussions <aspectj-dev@xxxxxxxxxxx>
> >
> >
> >
> > To
> >       Alexandre Vasseur <avasseur@xxxxxxxxx>, AspectJ developer discussions
> > <aspectj-dev@xxxxxxxxxxx>
> > cc
> >
> > Subject
> >       Re: [aspectj-dev] Regular expressions in pointcut expressions
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Alexandre Vasseur wrote:
> >
> >  >...
> >  >Perhaps you can reformulate, since it sounds a very bad idea to write
> >  >something like "set(...) && call(...)" since obviously there won't be
> >  >any match for that as those are 2 different joinpoint kind.
> >  >
> >  >
> >  >
> > Right. I skipped over some details, but basically the intent is to match
> > the 'set' join points where a corresponding method exists (or in
> > general, some corresponding condition is met). So, it would be more like
> > this:
> >
> > set (* \(*\).\(*\)) && if (exists (* $2.prefix$3(..)))
> >
> > or something like that. Note that even without the regular expression
> > stuff, it would nice to have "exists":
> >
> > set (private Foo.name) && if (exists (* Foo.prefixname(..)))
> >
> > (Perhaps the "if" is redundant...)
> >
> > Maybe it would also help to provide a few more details about why this is
> > interesting for my Contract4J experiments. Currently, the tool has you
> > define "design by contract" (DbC) tests using expressions in strings
> > inside special-purpose annotations. E.g.,
> >
> > @Pre ("n != null")
> > public void setName (String n) { this.name = n; }
> >
> > Which defines a "precondition" test that "it's illegal to call setName()
> > with a null argument."  Currently, rather than embed a runtime
> > expression interpreter, a precompilation step is done (with Sun's APT -
> > annotation processing tool) that generates aspects to implement the
> > tests. So, the string expression gets converted to code, which is then
> > compiled during the compilation step.
> >
> > One approach to eliminating the precompilation is to introduce a
> > JavaBeans-like convention where DbC tests have the same signature as the
> > methods they advise with a special prefix:
> >
> > public void setName (String n) { this.name = n; }
> > public boolean preSetName (String n) { return n != null; }
> >
> > For an attribute, I could define an invariant test that must always be
> > true after any change and before any read:
> >
> > private String name;
> > public boolean invarName () { return this.name != null; }
> >
> > So, I would like to write aspects that find these occurrances of  DbC
> > tests and their corresponding methods or fields and only advise the
> > methods or fields with before, after, or around advice (as appropriate)
> > to invoke the test methods.
> >
> > dean
> >
> > _______________________________________________
> > aspectj-dev mailing list
> > aspectj-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/aspectj-dev
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > aspectj-dev mailing list
> > aspectj-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/aspectj-dev
> 
> --
> Dean Wampler, Ph.D.
> dean at aspectprogramming.com
> http://www.aspectprogramming.com
> http://www.contract4j.org
> I want my tombstone to say:
>     Unknown Application Error in Dean Wampler.exe.
>     Application Terminated.
>     [Okay]    [Cancel]
> _______________________________________________
> aspectj-dev mailing list
> aspectj-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/aspectj-dev
> 


-- 
-- Adrian
adrian.colyer@xxxxxxxxx