Community
Participate
Working Groups
Build Identifier: 20120216-1857 I am not sure if this goes under the UI or Core component. Please re-assign if needed. If I bring up Content Assist after typing "new X" or "new XY" (where X and Y are any letters), the entire IDE freezes for a couple of seconds. I hear the disk churning. In fact, the thread "main" is reading a zip file and the thread "org.eclipse.jdt.internal.ui.text.JavaReconciler" is opening a file. If I type "new XYZ", then Content Assist appears quickly. I will attach a file of all the call stacks at the time of the freeze. If I could continue typing instead of waiting for Content Assist to show up that would be a good solution. A better solution would be to have a background thread create a cache after the IDE has started and is usable. Reproducible: Always Steps to Reproduce: 1. Type "new T" 2. Bring up Content Assist 3. Note the IDE freezes for a couple of seconds and the disk churns
Created attachment 213311 [details] Call stacks at the time of the freeze
Constructor content assist is expensive, so it can take a while. How many seconds are "a couple" for you? If it takes too long for you, you can reduce the timeout by setting the Java system property when starting Eclipse: eclipse.exe -vmargs -Dorg.eclipse.jdt.ui.codeAssistTimeout=3000 (the value is in ms)
I didn't time it with a stop watch, but it takes about 3-4 seconds. Is there any way to cache the results for constructor content assist? I set "Auto activation triggers for Java" to ".abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ". This makes Content Assist popup all the time. This really saves me a lot of keystrokes because most of the time I only have to hit 2-3 keys and Content Assist has the right identifier at the top of the list. I just press enter and get the identifier or method call. I hit the "new X" and "new XY" problem a lot because of the "Auto activation triggers". Sure, I could remove the auto activation but that would definitely be much slower than waiting for the "new X" and "new XY" problem. Setting the timeout lower is just a workaround. Thanks for the tip. I'll see how I like it.
(In reply to comment #3) > I didn't time it with a stop watch, but it takes about 3-4 seconds. Is there > any way to cache the results for constructor content assist? Are the subsequent content assist's on new X's faster? If not, increasing memory for the eclipse process could help.
I edited eclipse.ini and changed -Xmx384m to -Xmx1024m. I restarted Eclipse. This had no effect on the response time. In fact, I watched the heap usage progress bar in the lower left. I even connected JConsole to Eclipse and monitored the heap usage. The committed heap climbed to 272 MB. -Xmx384m vs -Xmx1024m didn't make any impact on response time. I noticed that there was 1 young garbage collection. So, I changed -Xms40m to -Xms1024m. This gets rid of the 1 young garbage collection, but there isn't really any change to response time. The 1 young garbage collection took very little time.
(In reply to comment #5) > I edited eclipse.ini and changed -Xmx384m to -Xmx1024m. I restarted Eclipse. > This had no effect on the response time. In fact, I watched the heap usage > progress bar in the lower left. I even connected JConsole to Eclipse and > monitored the heap usage. The committed heap climbed to 272 MB. -Xmx384m vs > -Xmx1024m didn't make any impact on response time. > > I noticed that there was 1 young garbage collection. So, I changed -Xms40m to > -Xms1024m. This gets rid of the 1 young garbage collection, but there isn't > really any change to response time. The 1 young garbage collection took very > little time. Can you please also confirm if the subsequent content assist on new X helps? The Java elements are cached and the cache size depends on the max memory. If subsequent content assist is faster, it could mean that the cache is not overflowing.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
