Performance problems with Eclipse/STS + Roo Project

[Wolfram]

I have another excerpt from my AJDT trace with some "suspicious" actions.

Here is the log (did not leave any message out, the "delete markers" message comes right after the "create x markers" also with no further action by me):

16:18:7 Timer event: 909ms: Total time spent in AJBuilder.build()
16:18:7 Timer event: 5ms: Update visualizer, xref, advice listeners for (separate thread): myapp
16:18:8 Timer event: 248ms: Delete markers: myapp (Finished deleting markers for myapp)
16:18:14 Timer event: 6056ms: Create markers: myapp (Finished creating markers for myapp)
16:18:14 Created 1737 markers in 247 files
16:18:14 Timer event: 284ms: Delete markers: myapp (Finished deleting markers for myapp)
16:18:20 Timer event: 6202ms: Create markers: myapp (Finished creating markers for myapp)
16:18:20 Created 1737 markers in 247 files

Right know, this happens every time I save a file, even when the only thing I did was deleting a whitespace character. All markers are deleted and created again, "sometimes" even twice. I can not find any trace messages corresponding to why this is done.
This behaviour does not appear right after starting up STS but I am unable to say at which point it changes.

(I guess this does not really belong in the Roo forum anymore as I am not even running Roo at this point.)

[Andy Clement]

Hi,

In the top right of the event trace view you can choose the message granularity, if you turn everything ON it should give you an indication of what is happening to lead to those marker messages.

Andy

[Wolfram]

Thanks for your reply.
The output actually was from a trace with everything included. I do not know why all markers are deleted and recreated (twice) every time the workspace is built or even if it has to be that way (I guess and hope not).

For now, I deactivated automatic building and CMD+B when I want it to build. So far that works for me and even the ~6 to 12 seconds wait is easier to cope with as it appears "onkeypress" and not implicitely on saving.

In the long run, I will of course have to find out what causes this behaviour as a 12 second loss on each save with no functional changes made is really annoying.

[Andy Clement]

Looking at the AJDT event trace it seems to me that everything is in order. It starts with (just one time after opening the project as it is supposed to):

Compiler configuration for project rootestproject doesn't know previous state, so assuming EVERYTHING has changed.

After a small local change in a source file + save:

Build kind = AUTOBUILD
kind of build requested=Incremental AspectJ compilation
Preparing for build: not going to be incremental because no successful previous full build
AspectJ reports build successful, build was: INCREMENTAL
Timer event: 11733ms: Total time spent in AJBuilder.build()

I'm slightly confused by the message that says "not going to be incremental" being immediately followed by "build was: INCREMENTAL". 11seconds for an incremental build is an eternity ... But I guess as long as it settles down, I won't worry too much about that.

What happens if I save a file with errors (I do press cmd+s a lot)? Andy indicated in his answer on another question by me that this might cause problems. That sounds reasonable to me, especially when Roo deletes its ".aj" files in the background due to a broken ".java" source.

That is interesting, you might be right about some interplay with the build in eclipse and when Roo is deleting/adding files in the background. Updating an aspect will probably just result in an incremental builld, but the addition or removal of aspects is actually likely to lead to full builds rather than incremental builds. hmmm... I'll talk to Ben (Alex) about this.

Also: Is it "normal" that an out-of-the-box STS 2.3.0 takes up 900MB of memory shortly after starting with one small Roo project (AspectJ) and only one source file opened? As I already mentioned this goes up to 1.6GB easily and might go even higher (no more memory available). I do have about 10 files open at a time.

that sounds a lot... I have 900Meg for my huge AspectJ projects, but not for something like petclinic Roo... do you have yourkit or something similar to give us an idea where the memory goes?

Andy

[aheusingfeld]

Hi,

I also experience these 10-20 seconds wait time on each save (on larger projects it can even take longer) with STS on roo projects. Setup is WinXP SP3, JDK6u18, STS2.3.0 but upgraded m2eclipse to 0.9.9!

Just as a small hint: In default roo projects there is also the maven builder which comes into play!

Here is the .project file of a simple roo project I created. It shows a bunch of builders:

<?xml version="1.0" encoding="UTF-8"?>
<projectDescription>
	<name>roo-test</name>
	<comment></comment>
	<projects>
	</projects>
	<buildSpec>
		<buildCommand>
			<name>org.eclipse.wst.jsdt.core.javascriptValidator</name>
			<arguments>
			</arguments>
		</buildCommand>
		<buildCommand>
			<name>org.eclipse.wst.common.project.facet.core.builder</name>
			<arguments>
			</arguments>
		</buildCommand>
		<buildCommand>
			<name>org.eclipse.wst.validation.validationbuilder</name>
			<arguments>
			</arguments>
		</buildCommand>
		<buildCommand>
			<name>org.eclipse.ajdt.core.ajbuilder</name>
			<arguments>
			</arguments>
		</buildCommand>
		<buildCommand>
			<name>org.springframework.ide.eclipse.core.springbuilder</name>
			<arguments>
			</arguments>
		</buildCommand>
		<buildCommand>
			<name>org.maven.ide.eclipse.maven2Builder</name>
			<arguments>
			</arguments>
		</buildCommand>
	</buildSpec>
	<natures>
		<nature>org.maven.ide.eclipse.maven2Nature</nature>
		<nature>org.eclipse.wst.common.project.facet.core.nature</nature>
		<nature>org.eclipse.jdt.core.javanature</nature>
		<nature>org.eclipse.wst.common.modulecore.ModuleCoreNature</nature>
		<nature>org.eclipse.jem.workbench.JavaEMFNature</nature>
		<nature>org.eclipse.ajdt.ui.ajnature</nature>
		<nature>com.springsource.sts.roo.core.nature</nature>
		<nature>org.springframework.ide.eclipse.core.springnature</nature>
		<nature>org.eclipse.wst.jsdt.core.jsNature</nature>
	</natures>
</projectDescription>

Also I found out that in my case most of the build time (and the afterwards occuring "validation" phase) is spend with getting the xsds for the spring (and spring security/ integration) xml files. It seems as if STS requests the xsds from the web instead of using the ones inside the according jar files.

@Wolfram Can you assure this isn't the case in your scenario?

Regards
Alex

[Christian Dupuis]

Also I found out that in my case most of the build time (and the afterwards occuring "validation" phase) is spend with getting the xsds for the spring (and spring security/ integration) xml files. It seems as if STS requests the xsds from the web instead of using the ones inside the according jar files.

Alex, the re-validation of Spring XML files is not triggered by changes to entities or aspects. So this is not the root cause. Additionally Wolfram is experiencing the slow builds on Eclipse JEE + AJDT; so no Spring validation of any sort.

Also how did you verify that STS "requests the xsds from the web ..."? Do you have some stacktraces or other evidence? In my tests, STS always uses the known XSDs from the Eclipse XML catalog.

Christian

[bytor99999]

Sorry to add onto this thread. On my Mac with the latest STS, it is extremely slow.

I definitely tell the students, when demoing Roo to them in class, that it is my fault and my settings on my machine running STS.

I don't change any setting because I actually prefer IntelliJ and only go into STS for class, and now my one personal project that I am using Roo for. But for me I can deal with the slowness when running the app, because I know once I "push-in" I am going to go back to IntelliJ.

Mark

[Christian Dupuis]

Sorry to add onto this thread. On my Mac with the latest STS, it is extremely slow.

What version of STS for Mac are you using? Any chance you are using one of the Cocoa packages? If so, please try the Carbon version as the Eclipse Cocoa port is known to have performance issues.

If not what concrete issues do you see? What is slow?

Christian

[aheusingfeld]

Hi Christian,

Alex, the re-validation of Spring XML files is not triggered by changes to entities or aspects. So this is not the root cause. Additionally Wolfram is experiencing the slow builds on Eclipse JEE + AJDT; so no Spring validation of any sort.

Also how did you verify that STS "requests the xsds from the web ..."? Do you have some stacktraces or other evidence? In my tests, STS always uses the known XSDs from the Eclipse XML catalog.

I tested this by simply removing the network plug from my laptop. STS/ Eclipse then complains that "loading of the required resources took longer than 60seconds...". I will try to reproduce that case and send you the eclipse error log by mail if that's ok.

I also come to this conclusion as changing e.g. the database config xml in a project (osgi bundle) other projects depend on (via maven) takes an eternity - even if there is only a blank line added.
Again I could send you a sample workspace (tested on winXP SP3+sun jdk6u18) but actually I'd like to test it against a clean STS2.3.1 installation to exclude any interference of my other eclipse plugins.

@Ben
If you turn off all validations for spring xml files does this only effect warning and error markers? Meaning
a) is context assistant still available
b) are aspectj markers still showing up

Alex

[bytor99999]

I am actually using the one that comes with the Mac installer for the Core Spring class. The latest Spring 3.0 class. I taught it two weeks ago and used the installer that is now on the pen drives.

Mark