On my multicore machine, Eclipse uses between 100 and 250 % CPU power, even when idling on a new plain install and an empty workspace. When actually doing things, it becomes slo
I've seen such behaviour only when the garbage collector went crazy because the allocated memory really reached the configured maximum memory limits of the VM. If you have a large Eclipse installation, your first step should always be to increase the memory settings in the eclipse.ini.
Please also activate Window -> Preferences -> General -> Show heap status. It will show you how much memory Eclipse currently uses (in the status line). If that goes up to the allowed maximum and doesn't drop anymore (i.e. the garbage collector cannot clean up unused objects), then that is exactly the indication for what I described above.
Edit: It would also be good to know what Eclipse package you use, as those contain different plugins by default. Classic, Modeling, Java EE developers,...?
I've had this problem with plugins, but never with Eclipse itself.
You can try to debug it by going to Help > About Eclipse > Installation details
and disabling the plugins one by one.
Uninstalling mylyn plugins fixed the issue for me and the performance boost was so drastic that I am posting it as answer to a 6 year old question.
Go to Help->About Eclipse->Installation Details->Installed Software
and uninstall all plugins that you know you are not using. I uninstalled only mylyn plugins and it did the wonder for me.
EDIT:
In the eclipse version : 2018-09 (4.9.0), the eclipse freeze/unresponsive issue can be solved by - closing the package & project explorer.
I know this may sound like a dumb solution, but I have tested this on about 5 peer machines, multiple times and believe me when I say this simple solution removed the freeze issue in each of them. As long as package/project explorer was not reopened, none of them complained about unresponsive eclipse.
Java multi thread garbage collector is a garbage. add -XX:-UseLoopPredicate option to java command line. See e.g. the bug https://bugzilla.redhat.com/show_bug.cgi?id=882968
I was having the same problem today, and it turned out to be an indexing thread that was occupying the CPU. I had recently added quite a bit of files to a project and had forgotten about it. I realize it's not likely that anyone else has this problem, but it might be useful to post how I investigated it.
I'm running Ubuntu 12.10 with STS based on eclipse Juno.
Allow it to settle for a bit, then get a listing of the cpu usage for each thread: ps -mo 'pid lwp stime time pcpu' -C java. Here's a sample of the output that identified my cpu hungry thread:
PID LWP STIME TIME %CPU
6974 - 07:42 00:15:51 133
7067 07:42 00:09:49 86.1
Convert the thread id (in my case 7067) to hex 0x1b9b (e.g. in the command line using: printf "0x%x\n" 7067)
Do a thread dump of the java process using kill -3: kill -3 6974. The output is saved in the file you redirected stdout when you started eclipse
Open the file and look for the hex id of the thread:
"Link Indexer Delayed Write-10" prio=10 tid=0x00007f66b801a800 nid=0x1b9b runnable [0x00007f66a9e46000]
java.lang.Thread.State: RUNNABLE
at com.ibm.etools.references.internal.bplustree.db.ExtentManager$WriteBack.r
Was facing the same issue, Passed following VM Argument in eclipse and it worked fine for me.
-Xmx1300m -XX:PermSize=256m -XX:MaxPermSize=256m