Community
Participate
Working Groups
When I launch Eclipse 3.0.0M8 the start of my default project takes about 25 minutes. Same is true when I wanna change the Classpath resp. make a CVS-update of the whole project. I have installed Java 1.4.2_04 for Eclipse and for the project 1.3.1_06. Yeah, the used project is little bit large (approx 20.000 separted files in 3.500 dirs with used approx. 2500 classes - historical splitted - cannot do much against history), nevertheless I don't see why it takes *that* long. My PC is Pentium III, 650 MHZ with 650MB physical memory. For the startup is use '-vmargs -Xms200M -Xmx512M'. So, is it problem of the project or why does Eclipse take *THAT* long? How to figure out?
Do you remember how long it took before & with which 3.0 builds (such as M7 or M6)?
I've tested it now with just downloaded and newly unpacked M6 and 2.1.3. Changing the Classpath takes around 30 min or so to rebuild the Workspace. My collegues are working either with IDEA or JBuilder, but it doesn't seem, that they experience the same behaviour.
I've forgotten to mentionen, how I launch Eclipse: start eclipse -vmargs -Xms200M -Xmx512M Otherwise I run out of Memory in Java.
Are they running on the same machine as you are (P3 650MHz)? Given the size of your project, I don't find the time to be that excessive. How often are you doing full builds?
Please reopen if you have compile/build times from your fellow employees (running on similar machines) that are substantially faster.
Somehow this issue is quite mysterious. I have Build all, in Preference 'Perform build automatically on resource modification' unchecked. I change an integer in a BoxLayout from 46 => 47 and everything starts to be rebuild and takes approx. 25 min before apps is launched. So, what is wrong in my system?
Why did you uncheck it? By doing so, eclipse is not incrementally building your workspace & keeping it up to date... each of these incremental builds should take a second (unless the changes are structural changes to signatures). How did you build your workspace? Did you choose 'Build All', or hit crtl-B? I suggest you check the auto-build option again & see what your performance is like.
I unchecked it, because it takes endless from one change to another. It's not the seconds I have to wait, it takes time :( Frankly said, currently don't know what I've changed in the environment, but is there a (easy) way to figure out, what the time consuming issue has it's base?
We cannot track it down if you don't give us concrete repeatable testcases. Saying it takes time but not timing the actual build doesn't help. We need concrete data. What changed in your source & how long did it take. Pull out your watch. ;) Also please answer all the questions. Q. How did you build your workspace when auto-build was turned off? Did you choose 'Build All', or hit crtl-B? Its much harder to predict how long a build will take with auto-build off since hundreds of changes could have taken place since the last time you built. Q. Do you run any ant tasks? If you do then you may be wiping out the entire build state & your builds will take forever.
OK, more detailed: Q1) Build All takes about 25 minutes. I've tried also with 'Clean' but didn't help. I think I've tried also Ctrl-B, and takes almost same time. Q2) No ant tasks for launching the app. The app should be simply using a Frame, which displayes a formely designed panel with VE. Code change was Label.settext ("...") to ("... Test"). Whereas I do not guess, that the changed labeltext would cause that tremendous workload. I launch the app, the old Panel is displayed (with "...") and next the rebuilt of the Workspace starts. And this will now take 25 min.
Ok so turn on auto-build & make the change again. Change it 3-4 times & see measure long it takes each time to change the string. 'Build All' & 'Clean...' are the same thing. DO NOT USE THEM unless you want to rebuild everything.
Sorry that should have read: Ok so turn on auto-build & make the change again. Change it 3-4 times & measure how long it takes each time to change the string.
OK, littl bit boring, but I've done so. I've changed the Label 3 times from which I have detailed time only for 09:46-10:16 = 30 min 10:17-10:45 = 28 min (the first launch is messy, because I've forgotten to Click on OK). What I've done? Change the Label caption, press launch. At this the Workspace start to be rebuilt and at the end time the new frame is gone displayed. Since I'm doing also other stuff, this time could be little less, but not dramatically. I've only done some kind of wordprocessing resp. another session of Eclipse open, where nothing much was worked on. And frankly said, I do not guess, I could reduce it more than to 25 min, but even if the time would be reduced to 20 min. that's TOOO long. So, there is some kind of performance problem, but where?
After some looking around (I wasn't able to use that setting for *real* working) I guess it is the problem with the Build, that one resource could not be resolved. But this Java-File is now in a Dir, which is in the Exclusion-List of the Project. Therefore I do not understand why this Dir of the Exclusion-List is ignored.
Created attachment 10596 [details] Exclusion List Obviously the Exclusion was added to the wrong Exclusion-List. Adding to the correct one, the Build works quite OK.
Sorry I didn't follow the last 2 comments. What are your build times now? Did you have a major build problem on the project? If you did then every build is a FULL build because we cannot successfully build the project.
Yeah, problem was that a full build was not possible. Now code change works within few seconds also start. Nevertheless, I do not understand why it is so ensential to make the exclusion in the correct property.
In the screen shot do you see the error in the problems view? Its says the project cannot be built, etc. Did you not see this? It explains the lengthy build times. Do you not keep the problems view open?
Yeah, I've seen this, but I assumed all the time that this path is excluded and unfortunately it wasn't all the time. I assumed, it is correctly configured and therefore, why this problem. Asking some collegues with Eclipse experience helped. Still don't udnerstand why the exclusion list is in this way so 'sensitive', but except of this, this issue if done.
Well for future reference, we do not generate build problems unless there IS a problem.
