Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 286521

Summary:	Performance Tuning a Build
Product:	z_Archived	Reporter:	David Carver <d_a_carver>
Component:	Dash Athena	Assignee:	Common Build Inbox <dash.commonbuilder-inbox>
Status:	RESOLVED WONTFIX	QA Contact:
Severity:	enhancement
Priority:	P3	CC:	dash.commonbuilder-inbox, kim.moir, manderse, nboldt, wayne.beaton
Version:	unspecified
Target Milestone:	---
Hardware:	PC
OS:	Linux
Whiteboard:
Bug Depends on:	292911
Bug Blocks:

Description David Carver

2009-08-13 10:12:09 EDT

There many different types of builds that can be done. Athena is very configurable in these aspects, but with so many options there needs to be some documentation around what can be done to help increase the build performance time.

With wst.xsl builds running a straight default athena setup, it can take up to 40 minutes to complete a build. This is a deterent to running a local build.

Some observations I saw:

1. No Incremental checkout support by PDE Build for when fetching map files or revisions. This causes uncessary Checkout times from the repository.

2. Unless doing a workspace build, checkouts always happen in a new workspace. Typical build infrastructures tend to use a common build workspace, and rely on a setting to say whether it's a clean build or incremental build.

3. Reduction of temp files and clean up. Athena/PDE Build produces a ton of temporary files. Is there a way to reduce this time? Clean up took nearly 5 to 6 minutes of the build time.

4. Which steps are absolutely necessary for a build. If I'm doing a true committers build, the only things I need to do is verify the following. Make sure the sources compile. Run the unit tests to make sure they work. Update Sites, Repository configuration, JAR signing, etc are not needed.

Running a similar configuration using Ant4Eclipse, the total build time is around 8 to 10 minutes including execution of the unit tests. Just to get to the point of running the unit tests with Athena took nearly 30 minutes (this does not include download time for the provisioning of the target environment).

Comment 1 Kim Moir

2009-08-13 10:24:01 EDT

The enhancement request for an incremental pde build is described in bug 154083

Comment 2 David Carver

2009-08-17 22:18:06 EDT

Here are a few things I'm noticing with Athena builds, and think they might be fairly simple to fix, by overriding some property settings.

Each Build is creating a new "scratch space" for lack of a better term.  This means that we aren't able to take advantage of some built in functionality from Ant's copy task.  It has to recopy all of the files or check all the files out even if the time stamp on the file hasn't changed.   For small projects this is not that noticeable but on a large plugin like org.eclipse.wst.xsl.xpath2.processor.tests with (28,731 files), it is very noticeable.

Ideally the only items that should end up in a New Build directory are those files that end up being part of the deliverable and binary build for testing purposes.

Current we have the following happening:

build
  3rd party
  download
  N20090410
     Source code
     Temporary Files
     Etc.
     Repositories
  N20090411
     Source code
     Temporary Files
     Etc.
     Repositories
 N20090411
     Source code
     Temporary Files
     Etc.
     Repositories

I would propose the following:

build
  3rd party
  download
  scratch pad
     plugins
        project
        project
     features
        project
        project
     test
        project
        project
  N20090411
    Final Artifacts from the Build

Use the scratch pad area for all builds, if using Hudson, it should have the ability to specify whether this is a clean build or an incremental build.  The Athena Builder should also have a properties switch to indicate clean or incremental.

If the build is told that this is a clean build, it wipes the scratch pad.  otherwise, it leaves the source files and we let hudson/copy task do an incremental update of only items that have changed.

The vast majority of Athena's build time is in copying/checking out files.  For larger projects we could greatly reduce the down time by optimizing how we copy files around and when.

Nick any thoughts or pointers where I could look to help?

Comment 3 Denis Roy

2009-08-18 08:38:09 EDT

(In reply to comment #2)
> It has to recopy all of the files or check all the files out
> even if the time stamp on the file hasn't changed.   For small projects this is
> not that noticeable but on a large plugin like
> org.eclipse.wst.xsl.xpath2.processor.tests with (28,731 files), it is very
> noticeable.


Wow.  Just wow.  Where has all the disk I/O gone...  Thanks for examining this, Dave.

Comment 4 Nick Boldt

2009-08-19 02:02:31 EDT

(In reply to comment #3)
> (In reply to comment #2)
> > It has to recopy all of the files or check all the files out
> > even if the time stamp on the file hasn't changed.   For small projects this is
> > not that noticeable but on a large plugin like
> > org.eclipse.wst.xsl.xpath2.processor.tests with (28,731 files), it is very
> > noticeable.
> 
> 
> Wow.  Just wow.  Where has all the disk I/O gone...  Thanks for examining this,
> Dave.
> 

To reuse the same build dir, you can set the new SNAPSHOT variable.

http://wiki.eclipse.org/Common_Build_Infrastructure/Athena_Progress_Report#2009-08-07

You could also configure the build to look at a local source cache (the one that Hudson uses to determine if a build is required), by setting these variables in your build.properties:

localSourceCheckoutDir=${WORKSPACE}/org.eclipse.gef
localSourceCheckoutDirExcludes=**/archive/**

But I agree, more documentation around perf turning and best practices is required.

Comment 5 David Carver

2009-11-02 09:13:04 EST

In bug 293863 I added a patch that should help on overall build times.  Basically when using fileset for deletes, it is best to delete the directories you don't care about, and then delete the individual files.  The way the fileset is designed it gathers both includes and excludes in the directory and all subdirectories (even if you don't specify it to search sub directories).  I've managed to reduce overall build times on the clean up step for wst.xsl and psychopath by about 20 mintutes in each case.

Also, I personally recommend cleaning and removing the eclipse working directory even if unit tests fail.  That directory alone counts for about half the disk space of a build.

Comment 6 Nick Boldt

2009-11-02 17:41:21 EST

(In reply to comment #5)
> In bug 293863 I added a patch that should help on overall build times. 
> Basically when using fileset for deletes, it is best to delete the directories
> you don't care about, and then delete the individual files.  The way the
> fileset is designed it gathers both includes and excludes in the directory and
> all subdirectories (even if you don't specify it to search sub directories). 
> I've managed to reduce overall build times on the clean up step for wst.xsl and
> psychopath by about 20 mintutes in each case.
> 
> Also, I personally recommend cleaning and removing the eclipse working
> directory even if unit tests fail.  That directory alone counts for about half
> the disk space of a build.

${buildDir}/eclipse is one big chunk, the other is ${buildDir}/testing. 

See bug 292911 comment 8. You can now set noclean=false to force this cleanup even if tests fail. Please test it and let me know if it works.

Comment 7 David Carver

2009-11-02 19:15:03 EST

(In reply to comment #6)
> > 
> > Also, I personally recommend cleaning and removing the eclipse working
> > directory even if unit tests fail.  That directory alone counts for about half
> > the disk space of a build.
> 
> ${buildDir}/eclipse is one big chunk, the other is ${buildDir}/testing. 
> 
> See bug 292911 comment 8. You can now set noclean=false to force this cleanup
> even if tests fail. Please test it and let me know if it works.

I added noclean and it didn't affect anything, of course the project I added it on didn't have any build failures, but it should be safe enough for people to use.

Personally, I think people should add something like the following to their ANT based Athena/Hudson build scripts:

	<target name="cleanUp">
		<delete dir="${buildDir}/eclipse" failonerror="false" />
		<delete dir="${buildDir}/testing" failonerror="false" />
		<delete dir="${buildDir}/compilelogs" failonerror="false"/>
		<delete dir="${buildDir}/testResults/consolelogs" failonerror="false"/>
		<delete dir="${buildDir}/testResults/html" failonerror="false"/>
		<delete>
			<fileset dir="${writableBuildRoot}">
				<include name="*AllFeatures*.zip, *Master*.zip "/>
			</fileset>
		</delete>
	</target>

Then in their run target at the end add:

  <antcall target="cleanUp"/>

Which will go through and clean up everything that they want cleaned.  Also, they should add a target like init that run depends on:

	<target name="init">
		<delete dir="${buildDir}" failonerror="false"/>
	</target>

Which if buildDir is set to the same name for everybuild, will delete and clean that directory before a build begins.

Comment 8 Wayne Beaton

2011-12-22 23:13:31 EST

WONTFIX; Athena has been terminated.