Community
Participate
Working Groups
Build ID: I20070209-1006 Steps To Reproduce: Working with a pretty big workspace and plugin/project. Certain operations such as rename refactoring and type hierarchy viewer (F4) can sometimes take 10-20 mins (not secs) to complete, while there is barely any I/O going on and the CPU usage hovers around 4-7% (from Eclipse, but otherwise quiet). Also the same thing goes for many other operations. Quick fix can often take from 30 sec - 2mins to appear. This was not the case a few versions ago (Eclipse and my project :-). Used to be a few seconds at most for Quick fix and Type hierarchy could take up to a minute on complex hierarchies, same for complex refactoring. More information: Eclipse is started with following, with Java 1.6 (latest): -vmargs -XX:MaxPermSize=128m -Xms256m -Xmx512m
Let me add that I increased the max memory to no avail. Had to kill a rename refactoring after 20 mins, was hung on checking pre-conditions. Still only on 2nd bar on the progress bar. I then did a call hierarchy for the method that I wanted to rename. That worked fine, coming in about 15 seconds with a list of about 40-50 entries.
One more thing to signal. I just used the refactor change method signature on the same method and that responded in about 30-45 secs to build the whole preview list. It really appears to be with certain functions only. I must just mentioned that this is always happening when the job is updating the progress bar located in the screen footer. Like if these are background tasks somehow, versus the change method signature that is running in a modal dialog. Not sure that this is related, just an observation.
Can you take a VM snapshot to see which thread(s) is/are consuming too much time (in the console, hit Ctrl+Pause and copy/paste the output in a file). Then attach this file to the bug, thanks. Can you also provide the eclipse build ID?
I tried by I simply have an hourglass and no ability to take control (other than canceling the job by pressing the cancel button). As for the build id, it is at the very top of this bug, but here again: Build ID: I20070209-1006
(In reply to comment #4) > I tried by I simply have an hourglass and no ability to take control (other > than canceling the job by pressing the cancel button). > I was not talking about Console view inside eclipse session but the MS-DOS window opened when you launch eclipse using -consoleLog argument. I should have been more precise on this point. > As for the build id, it is at the very top of this bug, but here again: Build > ID: I20070209-1006 > Ooops, sorry I missed it
These numbers really look insane, and we are not seeing anything like this. Clearly we need steps to reproduce.
(In reply to comment #6) Correct: I performed some tests using a large workspace (110 + projects), and did not experience any performance issue. We need a step by step scenario to reproduce.
Alain, any news on this ? Were you able to take a thread dump (start eclipse with -vm <path to your jdk>\bin\java.exe, then press Ctrl+Break in the DOS console) ?
(In reply to comment #8) Alain, any news about this problem? Do you still encounter this issue? Did you manage to gather a recreate step by step scenario?
No, the issue has disappear with upgrades (believe around 3.3M7).
Thanks for the feedback => close as WORKSFORME
Verified by user for 3.4M1 using build I20070802-0800.
