Bug 18259 - changing classpath causes significant recompilation
Summary: changing classpath causes significant recompilation
Status: VERIFIED WORKSFORME
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 2.0   Edit
Hardware: PC Windows 2000
: P3 normal (vote)
Target Milestone: 2.0 F2   Edit
Assignee: David Audel CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2002-05-29 20:14 EDT by John Wiegand CLA
Modified: 2002-06-03 10:51 EDT (History)
0 users

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description John Wiegand CLA 2002-05-29 20:14:50 EDT 
0529.

Import the source for all of the projects in eclipse.
If I change the required projects (remove org.eclipse.boot - it should rarely 
be used at all), I recompile the project (as expected), but also appear to 
recompile all of the downstream projects even though there was no change in the 
project itself (try org.eclipse.compare, for example)
Comment 1 Kent Johnson CLA 2002-05-30 15:32:42 EDT 
With org.eclipse.compare it took 8 seconds to rebuild the project (because of 
the classpath change) and 6 seconds to propagate all the 'new' class files to 
its dependent projects.

I don't see how dependent projects can know the 'new' class files from the full 
build were the same...

JW: Did it take considerably longer for you?
Comment 2 John Wiegand CLA 2002-05-30 16:37:46 EDT 
I should have flagged the time.  I have rerun the test.

My time (from the time I remove boot from compare's build path until the dialog 
disappears) is 30 seconds to compile compare + 30 seconds for the dependents - 
a 1 minute operation

By upping my memory from the default to 256M, the time became 15 seconds!

I was at the threshold and must have been getting many GCs.

Sorry for the red herring.
Comment 3 Kent Johnson CLA 2002-05-30 16:50:19 EDT 
Closed.
Comment 4 David Audel CLA 2002-06-03 10:51:35 EDT 
Verified.