Community
Participate
Working Groups
Build ID: M20071023-1652 Steps To Reproduce: In my own experience, while JDT is smart enough to do incremental rebuilds when you create a new class or delete an existing one, it does a full rebuild of a project (and of all of its dependant projects, if any), when: 1) you add or remove a source folder 2) you add or remove a JAR in its build path 3) you add or remove a required project in its build path 4) you change the order of src folders/JARs/projects in the project build path I always wondered why JDT incremental build mechanism doesn't apply in these cases... Shouldn't case 1) be equivalent to the creation (or deletion) of all the classes in the added/removed source folder? Shouldn't case 2) be equivalent to the creation (or deletion) of all the classes in the added/removed JARs? Shouldn't case 3) be equivalent to the creation (or deletion) of all the classes in the added/removed project? Shouldn't case 4) be, at worst, equivalent to the deletion and subsequent addition of all the classes in the moved src folders/JARs/projects? When you work with HUGE and/or MANY projects, any little modification on the build path of a project (say: you add a new -even empty!!- source folder) triggers a full rebuild that may take several minutes to complete. If this could be made better, I think it would be a significant performance enhancement. Some co-workers of mine refuse to turn automatic building on, just because they hate when Eclipse starts to do a full rebuild when it were not actually needed... More information:
Let's look at your cases. 1) you add or remove a source folder 2) you add or remove a JAR in its build path 3) you add or remove a required project in its build path 4) you change the order of src folders/JARs/projects in the project build path Adding... case 1) add a new source folder -> be equivalent to the creation of all the classes in the added source folder? Adding a new empty source folder is a noop & doesn't cause a full build. If you have proof that this isn't the case, please enter a repeatable testcase. Adding a new source folder with new classes is currently not an optimized case, but we can look into it. case 2) add a JAR in its build path -> be equivalent to the creation of all the classes in the added JARs? case 3) add a required project in its build path -> be equivalent to the creation of all the classes in the added project? These 2 cases fall into the same situation: too many class changes can be as slow or slower than a full build. Since these operations are not very common for most users/projects, I doubt we will optimize these cases for this release. Deleting... case 1) delete an existing source folder -> be equivalent to the deletion of all the classes in the removed source folder? Deleting an existing source folder is currently not an optimized case, but we can look into it. But again, its not a very common operation. case 2) delete a JAR from its build path -> be equivalent to the deletion of all the classes in the removed JARs? We do not have the list of classes in the deleted JAR file, nor is it worth to keep the list for every JAR file referenced by every project to handle the case that 1 may be deleted in the future. If the JAR file still exists on disk, can we trust that it hasn't changed? No we cannot. FYI, the builder doesn't know whether AUTO-BUILD is enabled or not. It relies on deltas from the resource level to indicate what has changed. Its possible that a JAR file could be replaced & then deleted before the next build, so the list of classes may be very different from what we compiled against. case 3) delete a required project from its build path -> be equivalent to the deletion of all the classes in the removed project? Deleting a required project will likely produce a large number of class changes and is not a common operation. case 4) change the order of src folders/JARs/projects in the project build path -> be equivalent to the deletion and subsequent addition of all the classes in the moved src folders/JARs/projects? Changing the order of the classpath affects numerous type references and is also not a very common operation. I suggest that if you're frequently altering the classpath of your existing large projects, that you disable AUTO-BUILD so all the changes are processed at the same time.
Hi Kent, IMHO the point is not just how frequent an operation can be, but how uselessly heavy it could be... This said, I can say that adding a JAR in the classpath or a new source folder can be not so rare... When you are working with tens of projects, with dependecies from each other, doing such an operation could become a pain: several minutes during which you can't do almost anything (I know, the build process goes in the background, but as soon as you try to save a file you're working on, the user process must wait for the build process to finish...). Also, remember that the build process may imply other non-Java building processing (like JSP and HTML validation on Dynamic Web Projects) that can be VERY VERY heavy and time consuming. Regarding the original points: CASE 1: I have the following situation: - project A (big), Java Project - project B (big), Dynamic Web Project which depends on A I just tried to create a new empty source folder or to create a new empty folder and add it to the build path in A, and it is actually almost a noop (I say almost, because there's an "Invoking validation" on project B that takes some time to complete, at least the first time). Then I tried to remove from the build path an empty source folder, by switching it back to "normal" folder: Eclipse required some minutes while indicating "Building workspace" (without specifying what it was actually doing: compiling? I could just see source folders flashing in "Package Explorer"...) Lastly, I tried to directly delete an empty source folder and the behaviour was the same. So, these operations are not actually "noops", although I must admit that a full rebuild seems not to be triggered. I appreciate the fact that you're considering to look at the cases of adding/removing non-empty source folders... CASE 2 & 3 (ADDITION OF JARs AND PROJECTS): I already said that I don't think these cases are so rare, although I was wondering whether, with HUGE projects, a full rebuild could really be faster than many class changes. Maybe the latter operation could require more pre-processing, but then the processing may be very light (depeding of what has changed), while a full rebuild will allways be heavy... In my personal experience, I can state for sure that, when I add a JAR or a Project to the build path, in most cases an incremental build would save a lot of CPU, because you're usually broadening the classpath, not breaking some previously correct compilation-time dependencies... CASE 2 & 3 (DELETION OF JARs AND PROJECTS): Ok, you are not keeping a list of classes in JARs. Could it be reasonable to create a list of all classes in a JAR as a pre-processing task on delete operation, so that incremental build could take place? I don't know how heavy this could be (maybe not much, if the JAR is not big...). Also, an heuristic on JAR size could help a bit to improve... Anyway, again I think that a heavy pre-processing could save a much heavier full rebuild process when you're working with big projects... At least, it would be nice if this could be configurable in preferences... CASE 4: My considerations are the same. To conclude, yes, I am actually forced to remove auto-build while adjusting my projects build paths... I think it would be nice if this could become an option, rather than an actual need to have a resonable user experience in such use cases. Thanks for your interest in this issue. Mauro.
Created attachment 126883 [details] Proposed patch Currently adding a new empty source folder does not require a full build. This patch detects the case of removing an empty source folder & launches an incremental build instead of a full build.
Released this patch for 3.5M6 Will leave the bug open for now to see if there are other cases we add improve.
