Bug 3137 - Performance: slow autobuild with many projects (1GL4NI5)
Summary: Performance: slow autobuild with many projects (1GL4NI5)
Status: RESOLVED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: Resources (show other bugs)
Version: 2.0   Edit
Hardware: All Windows NT
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: John Arthorne CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2001-10-10 22:50 EDT by John Arthorne CLA
Modified: 2001-10-25 11:20 EDT (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description John Arthorne CLA 2001-10-10 22:50:06 EDT
From EC (Stef van Dijk):

We have someone here who is moving a large number of projects from VAME to
Eclipse. We're talking about over 150 projects which are loaded into the
workspace at one time. Note that this is actually a normal configuration for
the type of work this person does. Having moved these projects, we are now
seeing a performance issue we don't quite understand.
Every time a file is changed, a progress dialog appears with an updating
message which says "Reading resource change information" followed by the
names of all the projects in the workspace. This dialog lasts about 20-30
seconds. Now if we were changing java source and there were numerous
interrelated projects I could understand, but that does not appear to be the
case.

For example, we created a brand new java project which has no references to
any of the other 150+ projects (nor do the other projects reference this new
one). We then created an .xml file in this project and opened it in an
editor. Everytime we save the .xml file, we see the progress dialog racing
through all the other projects in the workspace. Why is this? None of those
projects should be affected by this project, and certainly not by a change
to an .xml file.

Then Philippe said:

The "Reading resource change information" message indicates the Java
builder is asking the platform for the delta computations. 

When the build button is pressed, all Java projects are traversed to see
if they need to be rebuild based on the changes in them and the changes in
their prerequisites. Note that a change inside a resource file on the
classpath still need the Java builder to copy it into the binary output
location.


NOTES:

JohnA (10/5/2001 5:20:45 PM)
	A massive improvement here could be accomplished as follows:

		- find out the set of projects that have changed
		- for each builder, if any of its "interesting projects" have changed, invoke builder

	This would mean we don't even have to invoke the builder if we know it won't
	be interested in any changes.
Comment 1 John Arthorne CLA 2001-10-15 12:48:58 EDT
Fixed.  Summary of changes (all in BuildManager and ResourceDeltaFactory:

- not eagerly opening the tree for builds (means less tree layers)
- Before invoking a builder, compute dtree delta since last build and see if 
there are any changes to project this builder cares about.  If not, the builder 
is not invoked
- When builder requests a delta, see if that project has changed (by looking at 
dtree delta computed above), and return an empty delta if not changed (saves 
building a ResourceDelta naively).
- Cache the last ResourceDelta requested by a builder.  If the old and new trees 
haven't changed since last request, just return the cached copy.  The cache 
expires at the end of any build cycle to avoid holding onto large garbage 
structures.
Comment 2 DJ Houghton CLA 2001-10-24 06:45:38 EDT
PRODUCT VERSION:

R0.9

Comment 3 Rodrigo Peretti CLA 2001-10-25 11:20:15 EDT
Fixed in v205.