Community
Participate
Working Groups
Eclipse 3.4M4 Eclipse 3.4M5 Windows XP SP2 with up to date patches Running Eclipse on Sun Java 1.5.0_13 Eclipse 3.4M3 works like a champ. The problem started in M4, I reverted back to M3 waiting for M5. The problem is still in M5. Please ask questions to I can keep up with Eclipse builds! :) I've tested this by switching b/w M3 and M5. In M4 and M5, when I save a .java file in the Java Browsing perspective, the workspace appears to build a little slower than in M3 which I could live with but after the build workspace progress bar (bottom right of window) goes away, my CPU goes to 100% for a solid 20 seconds. This is a huge difference with M3, where I did not notice any side effects from saving a .java file. I have Build Automatically on of course. I've closed 2 huge projects but this problem does seem to be affected. I am running on a Pentium 4 at 3.06Ghz (1 core). My colleague is running a Dual Core (2 cores) at 2GHz and he sees his CPU go to 20-30% for 7-8 seconds after a save. So is this a bug or is Eclipse doing some extra new work after a save that did not exist in M3? Help! M5 is barely usable for me and being stuck on M3 is not where I want to stay. Thank you, Gary
Created attachment 89574 [details] CPU-Z HTML description of my CPU.
Created attachment 89575 [details] My project .settings in a ZIP file.
Please provide a thread dump when CPU is high and attach it to this bug report.
Attaching a stack trace from 3.4M3 and 3.4M5. For both stack trace: - In the Java Browsing perspective - Save a Java file - Bring the Eclipse console window to the foreground - Wait for the build workspace to finish and the CPU to go to 100% - Wait a couple of seconds while the CPU is at 100% - Crtl-Break to get the stack trace. The M5 stack trace contains 3 traces taken about 5, 15, and 30 seconds after the build workspace progress bar was finished. The CPU was at 100% the whole time.
Created attachment 89615 [details] One 3.4M3 stack trace
Created attachment 89616 [details] Three One 3.4M5 stack traces
Can you please try to close the Problems view and see if you still have the performance problem?
Steps I took: - Closed all views in the Java Browsing perspective. - Restarted Eclipse M5 - Viewed 10 Java files. - Save various files. The CPU does *not* jump to 100% after a build workspace. I used to have the following views open: Problem, JUnit, Console, Search, Hierarchy, Javadoc. If I open the Problems view, it takes 15 seconds of 100% CPU for the view update itself. When I change a public static final String and recompile, after a rebuild, it takes 20 seconds of 100% CPU for the view update itself. So the issue is definitely the Problems view. Changing the title of the ticket.
Oh, BTW, my problems view setting is "on selected element and its children"
Moving to Platform/UI
OK, I think I've partially fixed my problem. I did not have any Configurations selected in the Problems view 'Configure Contents' dialog. I selected both "All Errors" and "Warnings on Selection" and choose "on selected element and its children". Performance is OK now! The issue, I think, is that the Problems view settings were either not propagated correctly from M3 or the settings are so different that I was given a default set of settings, which were 'show everything' settings. Now that I think about it, every time I upgrade M releases, Eclipse seems to reset my Problems view settings because I recall having to reset my settings every time. So in short, my main issue appears to be solved but there could still be an issue in carrying over Problems view settings from previous version. Thank you for you help! Merci! Gary
This was fixed in M5 but we should verify against 3.3.2 again in M6.
Marking FIXED
Verified in I20080325-0100
