Community
Participate
Working Groups
build: F3 When I invoke content assist using Ctrl-Space in the Display view, it takes a >10 seconds for the list to come up. I hit a breakpoint and typed a variable in the display view, started to enter the first few characters of a method name, then hit Ctrl-Space. In my particular case it took 15 seconds for the list of 2 methods to come up. Doing content assist in the editor in the Debug perspective comes up in a reasonable amount of time, so I would expect the Display view could do it in the same amount of time.
I also noticed some slow code assist in the variables view, but now I cannot reproduce it.
It appears that content assist can be slow the first few times it is used on types that are not yet populated in the java model cache. Do you find that doing the same code assist operation is repeatedly slow, or only the first time?
It is repeatedly slow since I first invoked code assist for completion on the same method in the java editor before trying code assist in the Display view. Just to be sure, I tried the exact same code completion (same variable, same method) twice in a row in the Display view and both took around 15 seconds.
Deferred for post 2.0 investigation.
This one is really quite frustrating.
Paul, do you have a reproduceable test case? I do not see the problem.
Hi Darin, I created a brand new project, with a single class in it, and while in the Java Browsing perspective, setting break points is fine with a single class in the project. Even debugging this basic project is snappy setting/removing the break points. However, with two other projects which have 1,400 and ~1000 source files in them, the snappiness is gone. Seems to be related to the size of the project? I could attach one the projects as an entire directory to this bug if it would work for you (this is the jakarta-log4j module that I am working on so it's Open Source), the other project is proprietary and I couldn't provide that. I think you also responded to Bug #20487 regarding Content assist, and I'm thinking this is also related to the size of the debugging project. Both projects use the same VM, Sun JDK 1.4.2. Just changed to this new VM recently, but we were using Sun JDK 1.4.0 for many months with the same problems.
Many apologies, I confused my bug reports, my last comment should have been made to Bug #20355, although I do believe the symptoms are related.
Darin, I can confirm in my small project test case that the Content assist is exceptionally quick, but seems exceedingly slow in the aforementioned much larger projects, perhaps it is only while at a break point in a particular class file that causes this issue? I will endeavour to debug our project again and see if it is only in specific object code where the performance varies, and if so, try to attach the source code for review. cheers, Paul
Closing, as this test case is old. Note, I have entered bug 72683 with a test case in place of this bug.
*** This bug has been marked as a duplicate of 72683 ***
Cannot be a duplicate of bug 72683 which is a side effect of a post 3.0 change!
marking as won't fix. Problem has been addresses in currently supported versions.
