The auto complete stalls so frequently and for so long, I quit using it altogether.
-
Limc - Your comment was deleted before I could thank you: I'll post an answer to this message so that others can see the fix.– R HughesCommented Feb 12, 2011 at 3:08
-
Duplicate of stackoverflow.com/questions/3953012/…– Pēteris CauneCommented Feb 15, 2011 at 13:58
-
@Pēteris Caune - Thanks for the link. This is exactly what I was searching for and looks very promising. I see multiple solutions and work arounds I would like to try. The simplest would be rolling back to 3.5. I'll post the result after I have a chance to implement.– R HughesCommented Feb 15, 2011 at 19:17
Add a comment
|
4 Answers
I've had success with the following using Eclipse (Classic) 3.6.1 on Windows 7 x64.
"A workaround, until the fix is released in 3.6.2 is summarized here: http://groups.google.com/group/android-developers/msg/0f9d2a852e661cba"
(copied for convenience)
"You can replace your /plugins/ org.eclipse.jdt.core_3.6.1.v_A68_R36x.jar plugin with one from http://www.google.com/url?q=http://adt-addons.googlecode.com/svn/patches/org.eclipse.jdt.core_3.6.1.v_A68_R36x.zip&ei=vg5aTf2RIMrUgAeI-qTvDA&sa=X&oi=unauthorizedredirect&ct=targetlink&ust=1297749446528273&usg=AFQjCNFv7FGlTrnoVhRGE35JPjHxOwI_Bw and restart Eclipse. Content Assists will be much better. Just try it. Don't forget backup your original plugins. "
answered Feb 15, 2011 at 5:26
-
OMG, that did it. I dug through the side links and came back to this exact post. Code assist is scary fast to me now. Aparantly it's a well known issue if you know where to look. The key things to know are: 3.6(Helios) with Android ADT && 3.6 searching javadocs. Both are known issues on 3.6 - to be fixed in 3.7. per bugs.eclipse.org/bugs/show_bug.cgi?id=325829– R HughesCommented Feb 15, 2011 at 23:45
-
Yeah, code assist took several seconds on a new box with an i7-930 overclocked to 3.5 GHz, while it had been instantaneous on an older core 2 duo box. I realized it must've been a bug introduced in the newer version of eclipse I was using, and my search led me to stackoverflow.com/questions/3783461/… where John T provided the link to the patched plugin. Commented Feb 15, 2011 at 23:56
-
Your post solved something that's been driving me nuts forever. Thanks Jon :)– SteveCommented Jul 3, 2011 at 11:01
This solved part of my problem.
In preferences, I defaulted all the 'Java->Editor->Content assist' screens and the performance is much improved. Any lag I have now is due to system speed and is negligible. I've gone from minutes to seconds building the suggestion list.
UPDATE: This didn't completely solve my problem, but it got me close. The search continues...
UPDATE: I'm developing in Java for Android using the default packages that are included and any that might have come down during a update(in retrospect, maybe choosing update all in the SDk update might not have been wise). The timing is fairly consistent online and offline. I did a few tests and found the following:
Startup Eclipse and enter a line of code that can use a .toString(). Typing the '.' populates the auto complete within 2-3 seconds. Type a 't' and it takes 70-75 seconds. After that, 10 seconds. Diff objects do the same thing(75 the first time, 10 after that). It's the filtering process that appears to stall. My CPU does not max, Memory is OK, but the program will go not responding till it's done. Any typeahead gets cached and eventually filters the list when Eclipse starts responding.
-
Which libraries is it stalling for? The standard libraries are usually local, but it's possible to specify remote locations for documentation for other modules/libraries (so that it's pulling the information down over the network) which might cause your issue.– Thorn GCommented Feb 15, 2011 at 0:58
For me the problem went away when I increased the memory for the vm. Put this in your eclipse.ini:
-Xms512m
-Xmx1024m
-
I didn't notice a difference, but did finally notice something I hadn't before. The first time auto copletion has to populate, it takes about 75 seconds. The second time on the same object, it only takes about 10. Obviously, it's caching the list and is not too bad. The next test is to see what happens with other objects in the same project.– R HughesCommented Feb 14, 2011 at 23:50
-
Actually my solution will not fix the problem, as you clearly point out. I experienced the delay myself yesterday, after a long time of trouble free usage. I didn't change any settings, the problem just decided for itself to come back. Weird. I don't see these insane times as you have, 75 secs and 10 secs. For me it's usually instant, apart from that one time yesterday, with a lockup of 30-45 secs. For comparison I'm using Ubuntu Maverick-64 with 4GB ram.– RobertCommented Feb 15, 2011 at 8:39
-
Sorry for jinxing you. I think my insane times are due to hardware. It's just a XP Pro dual core Intel T2400(2GHz) with 2GB RAM. Pēteris Caune posted a good link above that I plan to explore. It leads to some other useful resources that might just solve it for me.– R HughesCommented Feb 15, 2011 at 19:13
-
Problem solved. Take a look at the answer just in case you ever need it.– R HughesCommented Feb 15, 2011 at 23:50
on my 4GB Windows Vista system this would happen A LOT !! (as well as debug issues when looking up variables).
This all went away after I built my new PC with 8GB RAM. I can now run 4 emulators simultaneously and it doesn't have any debug problems any more either. Auto complete with huge lists also works just fine.
it would seem to be just an issue with how much RAM you've got.
answered Mar 24, 2011 at 7:05
-
I tried to test it by running simultaneously: Photoshop CS5, Visual Studio 2010, WinAMP with visualization, eclipse, 4 emulators... Eclipse remained rock solid in terms of performance on my 8GB system. No way could I do that on 4GB because Eclipse would choke if I ran it along with Visual Studio. Commented Mar 24, 2011 at 7:07