See snapshot in issue #171093
Honza's RunOffAWT can be used to start the substituteText outside AWT.
See also issue #172700.
*** Issue 169331 has been marked as a duplicate of this issue. ***
*** Issue 173765 has been marked as a duplicate of this issue. ***
This issue already has 20 duplicates
This issue already has 22 duplicates
It was automatically made P2 by the exception reporter. I have already filed issue that this should not happen for slowness detected. Making it back to P3.
*** Bug 176826 has been marked as a duplicate of this bug. ***
Created attachment 91240 [details]
This bug already has 50 duplicates
Created attachment 92494 [details]
*** Bug 171436 has been marked as a duplicate of this bug. ***
*** Bug 177749 has been marked as a duplicate of this bug. ***
I just waited 19s after pressing Ctrl-Space. According to UI Responsiveness guidelines, this qualifies for higher priority than P3. Increasing.
There are two types of slowness.
1st) reported by Jarda - I will fix it
2nd) IO contention - I will create a blocking issue on FS as the cc calls runPriorityIO but the VCS is still active.
I don't think it is a good idea to reschedule the code completion's substituteText outside of AWT. Doing so would lead to the unpredictable code completion results (e.g. sometimes a type name would be completed without adding corresponding import statement, sometimes a method call would be completed without initial parameter guess, etc.) which could be quite confusing for users. It's IMHO better to focus on finding and eliminating the code completion blockers instead. Looking at the exception reports, half of them shows that substituteText is blocked by slowness in JavaCompletionQuery.resolveDocumentation(). This could be fixed by making JavaCompletionQuery.resolveDocumentation() cancelable. Other half of the reports end with calling com.sun.tools.javac.jvm.ClassReader.readInputStream, which usually means that there is an IO contention with some other IO intensive task.
Fix as you want. Making some tasks cancelable sounds good.
On the other hand, the code completion has to be responsive even if the I/O load is high. I guess it is quite common to run build, run test, etc. and still code something in editor.
>On the other hand, the code completion has to be responsive even if the IO load is high.
The question is how you define "responsive". I agree that the cc has to work but when loading the data to resolve the symbols take 3 seconds the code completion cannot be faster than 3 seconds. It's obvious that under high IO load the cc will be affected by the load itself and will be slower. It's impossible to cache all the symbols in memory as it can have size of 100s of megs.
It's the same as with IDE start, the IDE starts slower when there is IO load.
Anyway I will create an issue on filesystems as the cc is using runPriorityIO which solved several of reports but not all. There is still contention with VCS.
On Machines which are starved for memory, or on which "Windows" is doing its usually terrible job at VM management, some of the codepaths for CC involve loading tons of classes. In cases where CC code is swapped out, or not in the RSS, my machine is a pig. The disk light comes on for minutes, sometimes and nothing in the IDE works.
It seems to me, that there should be a window opened immediately, for CC and it should say something like "Please wait..." or "Collecting Choices...", and it should have a close button on it that cancels the task. That would at least give the user feedback, and a timer could be used to change the message to something which might help the user understand that there are resource problems in the machine causing things to be slow.
Having some statistics about how long previous progress to key points might allow a colored progress bar, with some simple text on it to show what step is causing the unexpected delay.
UI responsiveness is not about being fast. It is about being responsive. We have to avoid situations where CC blocks the whole UI (for 19s in my yesterday's report!). CC responsiveness falls into the same category as typing characters in editor. Regardless of any I/O (build, tests, Hg, etc.) that has to be fast too. CC as well as typing shall not block AWT thread for more than 100ms.
>for 19s in my yesterday's report!
Jardo, did you read my comment #14?
In this comment I classified this issue into 2 completely different problems.
1st) Your case - the 19s delay, which is caused by EDT thread waiting on lock . This is real problem and it's already fixed. I will commit the fix after API review.
2nd) IO contention - the dalay is ~ 3 sec. This has two cases:
a) Checking for external changes - fixed by runPriorityIO
b) VCS - as far as I know you have this in performance team todo
Added dependency on VCS issue (the IO contention case).
The biggest problem (calling slow query under lock) is fixed. The rest of problems depends on the issue #186148.
*** Bug 199718 has been marked as a duplicate of this bug. ***
*** Bug 176568 has been marked as a duplicate of this bug. ***
*** Bug 211953 has been marked as a duplicate of this bug. ***
18s, does not that classify the bug as P2 according to http://wiki.netbeans.org/BugPriorityGuidelines? "UI responsiveness of a feature breaking UI guidelines (100ms, 1s)"
Re. " Your case - the 19s delay, which is caused by EDT thread waiting on lock . This is real problem and it's already fixed. I will commit the fix after API review." - the UI was blocked for 19s just a while ago, so I expect there is some regression in 7.2 builds.
Fixed in jet-main.
Integrated into 'main-golden', will be available in build *201206080001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
User: Dusan Balek <firstname.lastname@example.org>
Log: Issue #171183: Code completion substituteText should be done outside of AWT - fixed.