RE: [aspectj-users] Overall problem with AJDT performance

[Thomas Hofmann <email@xxxxxxxxxxxxxxxxx>]

Hi Andy,

yes we have Ant driven builds. One for the Rich Client Application (based on Eclipse RCP) and one for the J2EE server part that produces an EAR file.
The former runs about 12-15 minutes but it does not contain the projects with .ass. in the project / package names. The project that took more than 12 minutes to build was one of these server projects. The other one was a test project which also isn't part of the client build. The creation of the EAR file uses Ant tasks that take what is already compiled in the eclipse workspace so I have no other numbers for that part.

I'm not sure if my pointcuts are well written. My experience with AspectJ is not that big. Anyway, I can say that the aspects that are woven into the application.ass project (the one that takes more than 12 minutes) don't use within().I'm not quite sure what would be the benefit of using within. Almost all classes in the project need to have the advice applied.

I'm using mostly execution and call together with matching based on types.

Let me give you some more details for the most problematic project:
com.dcx.ivkmds.application.ass

It contains repositories that handle persistence using Hibernate internally. There is a Java interface and an implementation based on Hibernate for each repository. In addition there are some utility classes but only a few.

I don't see how within() would make much difference in terms of types affected (but of course I would like to learn if I'm wrong).

The aspects that are applied reside in another project: com.dcx.ivkmds.fwk.ass. This a part of our "framework". The aspects in this project apply to other projects that make use of the framework, not just to com.dcx.ivkmds.application.ass.

com.dcx.ivkmds.fwk.ass contains the following aspects:

AssComponentAspect:
Contains ITDs for all classes that implement the AssComponent interface.

BaseSessionLifecycleControl:
Is an abstract aspect that contains an around advice to open and close the Hibernate session. It contains an abstract pointcut that subclasses of the aspect may you to specify the boundaries for Hibernate sessions.

SessionLifecycleControl:
A concrete subclass of BaseSessionLifecycleControl. It contains the pointcut that determines where the advice is to be applied.

MeasuringPoint:
Contains pointcuts and advice for performance logging.

DatabaseConnectionCustomization:
Contains two after advices and one before advice to make 3rd party JDBC driver specific calls on the JDBC connection when a new connection is retrieved.

DatabaseErrorTransformation:
Uses an around advice to add special error handling for exceptions from the database. The are inspected and transformed to application specific exception types.


Only the last three aspects apply to the classes in com.dcx.ivkmds.application.ass.

Will the other three aspects visible on the aspect path of com.dcx.ivkmds.application.ass have a great negative performance impact? Would this require within()?

What I don't like about within() is that it kind of turns dependencies around. If I need to specify within() in the aspects that are part of the framework I need to know what other parts of the framework make use of them.
I even have to make the clients of the framework visible to the framework. This would result in cycles I believe.

I would be glad to try out a debug build that would provide more insight into where the time is spent.
Regarding yourkit I can only say that I don't have a license for it. I could probably use the 15 day evalutation version but would need to get some instructions on how to configure it to filter the classes your are interessted in.

My eclipse wasn't running short of memory. Heap space was 1200 MB. During the build 600-900 MB were used (which is too much - but this is a different issue).

I can give you more details on the aspects but I don't want to spam the mailing list. So please tell me if you think this is the right place to discuss these issues. I could also open a bug in bugzilla or we could use direct email or skype for example to exchange further details.
Posting lots of source code to the mailing list or bugzilla is not what I want to do. I would prefer direct (not public) communication for this.

Do you see any obvious problems with the setup I described above?

Regards,

Thomas


-----Original Message-----
From: aspectj-users-bounces@xxxxxxxxxxx [mailto:aspectj-users-bounces@xxxxxxxxxxx] On Behalf Of Andy Clement
Sent: Donnerstag, 8. Oktober 2009 17:37
To: aspectj-users@xxxxxxxxxxx
Subject: Re: [aspectj-users] Overall problem with AJDT performance

Hi Thomas,

Those build times do look unreasonable.  Do you do product builds
outside of eclipse (perhaps Ant driven) - do these builds exhibit the
same issue?

I've never seen a project build take 12minutes so clearly something
unusual is happening.  I presume all your aspects are using well
written pointcuts that involve scoping within() clauses and don't just
attempt matching with just kinded pointcuts (like execution).  To see
all the affected joinpoints in one place, you can turn on the
weaveinfo info messages for the project.  Are you using ITDs?

I think we need more visibility into the build time - I could do you a
debug build of the plugins that will include extra stats about where
the time goes.  (Or even better you could do a yourkit profile and
send it to me? That would make it obvious).

Oh, and is your eclipse running tight on memory?  I wondered if you
were running near the limit and it was thrashing.

Andy


2009/10/8 Thomas Hofmann <email@xxxxxxxxxxxxxxxxx>:
> Hi Andy, Andrew J
>
>
>
> I'm still having problems with the performance of AJDT and AspectJ in my
> workspace.
>
>
>
> Let me start by describing my environment:
>
>
>
> Thinkpad T61p
>
>
>
> Eclipse Java EE IDE for Web Developers.
>
> Version: 1.2.0.20090621-0820
>
> Build id: 20090621-0832
>
> based on Eclipse 3.5.0
>
>
>
> Version: 2.0.1.e35x-20091001-1600
>
> AspectJ version: 1.6.6.20090930185500
>
>
>
> The workspace contains about 148 Java projects (and some others like
> features, project set projects etc.)
>
>
>
> I disabled Build Automatically, restarted Eclipse and then cleaned the whole
> workspace. Then I started the build with Build All. The AJDT trace was set
> to the default values and opened. It is attached to this mail.
>
>
>
> Here are the most relevant parts:
>
>
>
> Line 192: 13:50:34 Project=com.dcx.ivkmds.application.ass, kind of build
> requested=Full AspectJ compilation
>
> Line 208: 14:3:17 Types affected during build = 292
>
> Line 211:Timer event: 766396ms: Total time spent in AJBuilder.build() ->
> more than 12 minutes!
>
> Line 707: 14:22:6 Timer event: 117857ms: Create markers:
> com.dcx.ivkmds.application.ass (Finished creating markers for
> com.dcx.ivkmds.application.ass)
>
>
>
> Line 370: 14:10:32 Project=com.dcx.ivkmds.fwk.test.ass, kind of build
> requested=Full AspectJ compilation
>
> Line 387: 14:18:45 Types affected during build = 24
>
> Line 390; 14:18:46 Timer event: 493759ms: Total time spent in
> AJBuilder.build() -> more than 8 minutes!
>
>
>
> Line 701: 14:21:10 Timer event: 62468ms: Create markers:
> com.dcx.ivkmds.fwk.test.ass (Finished creating markers for
> com.dcx.ivkmds.fwk.test.ass)
>
>
>
> I figure that the types in these projects have a lot of joinpoints. Is there
> any place where I can see the number of joinpoints in these projects?
>
>
>
> Actually, the number of types involved isn't very high I would say.
>
>
>
> So the question is are these compile / weave times normal? For us it is a
> major problem when the time to rebuild the whole workspace takes 38 minutes.
>
>
>
> Is there anything I could try to do to improve the performance besides
> reducing the number of joinpoints?
>
>
>
> I really like the benefit AspectJ provides but under these circumstances it
> is very unpleasant and difficult to work with it.
>
>
>
> I'm looking forward to your reply.
>
>
>
> Regards,
>
>
>
> Thomas
>
>
>
>
>
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>
>
_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-users