Community
Participate
Working Groups
Our developers have around 300 projects in their workspace, and we have just iniiated the use of AspectJ 1.2.0.20041004170512 in our projects. We're all running Eclipse version 3.0 or 3.0.1. We currently have around 15 projects containing weaved-in Aspect code. After performing a "Project->Clean..." on any of these AspectJ projects, a subsequent rebuild takes anywhere from 45 minutes to over 2 hours. Whereas before, the folders shown in the build progress changed so quickly you could barely read them, now each folder is displayed for at least 10-15 seconds, sometimes for a minute or two, and a few for 10-15 minutes. This problem is bringing our productivity to a crawl.
Additional email correspondence about this: Me: This could be an eclipse issue - which build of eclipse are you using, and which platform? And does increasing the heap size help? AspectJ projects can require quite a bit of memory. John: We're running both Eclipse 3.0 and 3.0.1, depending upon the developer. Everyone is running on a Windows XP platform. We've already got our heap sizes set to at least 512MB. We can try higher values, but it's getting to the point where it's not very practical to raise the value much higher. Me: I can't say whether that is enough as I don't know how big your projects are. AspectJ projects do in general require more memory than Java projects. A heap of 256MB is enough to develop AJDT itself, but that's only about 10 plugins. Please could you try a larger heap, just to see if that is the problem - if the build times significantly improve, then it probably is. Please add any findings to this bug.
John, have you been able to try this with a larger heap, to see if that improves the situation? It would be good to know whether this is a case of excessive memory requirements (which we plan to look at soon), or whether there is a separate problem here.
Hi - I'm not sure if this is relevent or not, but just as a note, our Builder doesn't actually override the clean method in IncrementalProjectBuilder. It is advised that you do override this. It might be worth doing this :-) Thanks, Helen
In the absence of any further information, I'm going to assume that this is a memory usage issue, and treat as a duplicate of 44215. If the JVM has an almost full heap, then excessive amounts of GC will be required, degrading performance. *** This bug has been marked as a duplicate of 44215 ***
