Re: [aspectwerkz-user] Speeding up roundtrip

Mattias, You may use

src\jdk15\test\test\weavebench to tune the weaver and such.

This basically generate N classes with M methods in. In each class,
each method m calls the m+1 method.

The app forces loading of the M classes (hence weaving) and calls
method_0 (hence calls everything).

You may change it some to bench weaving scenarios with
- constructors execution and calls
- field get/set
- overhead in the weaving time when private member are encountered
(since we create extra wrappers), or when more complex pointcuts are
used (change some the line        
sd.addDeploymentScope(DeploymentScope.MATCH_ALL);)
- when annotations are used (you ll need to then generate classes with
annotations, which should be rather simple).
etc

I 'll play with it in the next days, this alongside the JRockit
tooling we have shipped with 1.5 :
http://dev2dev.bea.com/wljrockit/tools.html , register, it 's free and
great products that can be used on production systems as well - sorry
for the plug!

Alex

On 7/5/05, Alexandre Vasseur <[email protected]> wrote:
> Hi Mattias
> 
> I cannot reproduce the weaver run based on the class and build.xml /
> aop.xml file you sent since those are missing dependancies (f.e. looks
> like log4j is used in the aspect, and thus needed to simply register
> the aspect).
> I don't know if it is the best option to send me the whole app (but go
> ahead if you think it is, as long as I don't loose time in setting up
> things to reproduce it)
> 
> One interesting thing would perhaps be that you run a profiler when
> doing the weaving and analyse that yourself.
> Alex
> 
> On 6/22/05, Mattias Jiderhamn <[email protected]> wrote:
> > http://jira.codehaus.org/browse/AW-460
> >
> > (Classes sent to Alex off list)
> >
> > At 2005-06-21 15:15, you wrote:
> > >yes file a JIRA
> > >
> > >If possible send me just the aop.xml file and the unweaved class files
> > >you are weaving with the script you are using so that I can do the
> > >weaving phase myself
> > >Alex
> > >
> > >On 6/21/05, Mattias Jiderhamn <[email protected]> wrote:
> > > > At 2005-06-21 14:12, you wrote:
> > > > >The pointcut:
> > > > >  ( execution(* se.exder.system.EntityObject+.update*(..))
> > > > >               OR execution(* se.exder.system.EntityObject+.delete*(..))
> > > > >               OR execution(* se.exder.system.EntityObject+.insert*(..)) )
> > > > >             AND !within(se.exder.logic.edi.GeneratedEdiLogObject+)
> > > > >is actually expensive since it means that we need to get the complete
> > > > >class hierarchy for every single class to see if the currently weaved
> > > > >class extends se.exder.system.EntityObject
> > > >
> > > > Ah, of course.
> > > >
> > > > >You may try to use a "within(<the package of the target app>) && ..."
> > > > >prefix perhaps (even as simple as "within(se..*)" actually to f.e.
> > > > >quicly bypass third parties dependencies at least under a load time
> > > > >weaving scheme.
> > > >
> > > > Tried to change this to
> > > >            within(se.exder..*.*Object) AND
> > > >            ( execution(* se.exder.system.EntityObject+.update*(..))
> > > >              OR execution(* se.exder.system.EntityObject+.delete*(..))
> > > >              OR execution(* se.exder.system.EntityObject+.insert*(..)) )
> > > >            AND !within(se.exder.logic.edi.GeneratedEdiLogObject+)
> > > > but it didn't seems to help a bit. Took about 55
> > > > seconds, compared to 10 secs without any weaving.
> > > >
> > > >
> > > > As for separate output directory, should I create
> > > > a JIRA entry for this feature request?
> > > >
> > > > >To do more diagnostic I would need the app itself I guess.
> > > >
> > > > Hmmm. What would you need? WAR + sources?
> > > >
> > > >   /Mattias J
> > > >
> > > > >On 6/21/05, Mattias Jiderhamn <[email protected]> wrote:
> > > > > > At 2005-06-21 13:03, you wrote:
> > > > > > >You perhaps need to see how the matching is done using
> > > > > > >-Daspectwerkz.transform.details=true
> > > > > > >That may help to narrow call side (call/get/set) pointcuts f.e. One
> > > > > > >such pointcut can indeed sometime lead to parsing everry single
> > > > > > >bytecode instruction.
> > > > > >
> > > > > > We only have execution() pointcuts.
> > > > > >
> > > > > > >Aside you may use include/exclude element in your aop.xm if you know
> > > > > > >that some files will not be weaved at all.
> > > > > >
> > > > > > We have made sure only to weave the ordinary
> > > > > > classes, not the JSP classes, but there are
> > > > > pointcuts in lots of the classes.
> > > > > >
> > > > > > I don't think there is much room for optimizing
> > > > > > the pointcuts. But I will post the aop.xml below
> > > > > > to see if anybody has suggestions.
> > > > > >
> > > > > > >AspectWerkzC does not support writing to a different location.
> > > > > >
> > > > > > Could this be added?
> > > > > >
> > > > > > >On the other hand you may be able to implement a wrapper that checks
> > > > > > >for .class file timestamps to compile only modified files (then keep
> > > > > > >track of the lastRun timestamp in some per project file)
> > > > > >
> > > > > > Only this wrapper, without writing to a different
> > > > > > location wouldn't helpt that much, since I would
> > > > > > then have to copy all the files before
> > > > > weaving, or the compilation won't work.
> > > > > > If the original .class was not overwritten, I
> > > > > > wouldn't need a timestamp file, but only compare
> > > > > > the timestamp of weaved .class with the original.
> > > > > >
> > > > > >
> > > > > > --------- aop.xml ---------------
> > > > > >
> > > > > > <aspectwerkz>
> > > > > >      <system id="exder">
> > > > > >        <aspect class="se.exder.system.persistence.JTAAspect">
> > > > > >          <advice name="txByType" type="around"
> > > > > >
> > > bind-to="execution(@se.exder.system.persistence.Tx * se.exder..*.*(..))" />
> > > > > >          <pointcut name="objectModification">
> > > > > >            ( execution(* se.exder.system.EntityObject+.update*(..))
> > > > > >              OR execution(* se.exder.system.EntityObject+.delete*(..))
> > > > > >              OR execution(*
> > > se.exder.system.EntityObject+.insert*(..)) )
> > > > > >            AND !within(se.exder.logic.edi.GeneratedEdiLogObject+)
> > > > > >          </pointcut>
> > > > > >          <advice name="txMandatory" type="around"
> > > > > > bind-to="objectModification" />
> > > > > >        </aspect>
> > > > > >      </system>
> > > > > > </aspectwerkz>
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > >On 6/21/05, Mattias Jiderhamn <[email protected]> wrote:
> > > > > > > > Our application is big enough to require a few
> > > > > > > > minutes of offline weaving on my machine, so we
> > > > > > > > use online weaving in development. On the other
> > > > > > > > hand, reloading the application in the web
> > > > > > > > container using online weaving isn't much better
> > > > > > > > (say ½-1 minute). This makes developing very
> > > > > > > > slow, since the code-compile-test
> > > cycle has a lot of weaving overhead.
> > > > > > > >
> > > > > > > > Is there any better way to do this? Can I have
> > > > > > > > AspectWerkz weave only modified classes offline?
> > > > > > > > If I weave the whole project and then try to
> > > > > > > > compile in my IDE (IntelliJ), I get compiler
> > > > > > > > errors. Could I make AspectWerkzC output the
> > > > > > > > weaved files in a different directory, so that I
> > > > > > > > can compile from the IDE and then have
> > > > > > > > AspectWerkz weave the modified classes only?
> > > > > > > >
> > > > > > > > Thanks in advance,
> > > > > > > >    Mattias Jiderhamn
> > > > > > > >
> > > > > > > >
> > > > > >
> > > > > >
> > > >
> > > >
> >
> >
>