This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
|Summary:||[69cat] Code completion substituteText should be done outside of AWT|
|Product:||java||Reporter:||Tomas Zezula <tzezula>|
|Component:||Editor||Assignee:||Dusan Balek <dbalek>|
|Severity:||blocker||CC:||akobberup, aldobrucale, alexey_vladykin, alied, andresdelacroix, aquaglia, ardan, arittner, athompson, bartvdc, black_algo, bokc, cyhelsky, darkzlayer, dstrupl, dwuysan, exceptions_reporter, faissalb, falven, FrantaM, gerzhedowich, gilbertoca, gorrus, greggwon, gtg, gualtiero65, hair, henda, herve, hideraldo.mello, hmichel, iceman81, ijay, Iksa, janario, jbecicka, jmborer, jmichelberger, jtulach, jyeary, keidson, leomachadop, leonhad, lhochet, lolo_101, mhuebner, michael.nischt, michal.owsiak, michbarsinai, miguelcpjava, misterm, mjanicek, mklaehn, mkristofic, mmirilovic, mr.prerak, mschneider, muellermi, netacq_server, Onofre, ovk, ovrabec, pflaska, pjiricka, rfvizarra, ripeel, sachith.dickwella, sebglon, sgtgarcia, sphinx1508, sreder, static_void, sworisbreathing, tapehead, tim_sa, tnleeuw, totop, white_merovingian, williambacchi, xlr, x_cat, yardus, _m4c0_|
|Issue Type:||DEFECT||Exception Reporter:|
|Bug Depends on:||186148, 188209|
Description Tomas Zezula 2009-08-31 15:23:27 UTC
See snapshot in issue #171093 Honza's RunOffAWT can be used to start the substituteText outside AWT.
Comment 1 Jan Lahoda 2009-09-21 19:04:36 UTC
See also issue #172700.
Comment 2 Dusan Balek 2009-09-23 13:37:30 UTC
*** Issue 169331 has been marked as a duplicate of this issue. ***
Comment 3 Dusan Balek 2009-10-06 15:36:22 UTC
*** Issue 173765 has been marked as a duplicate of this issue. ***
Comment 4 Exceptions Reporter 2009-11-11 08:34:52 UTC
This issue already has 20 duplicates see http://statistics.netbeans.org/exceptions/detail.do?id=154357
Comment 5 Exceptions Reporter 2009-11-13 07:11:34 UTC
This issue already has 22 duplicates see http://statistics.netbeans.org/exceptions/detail.do?id=154357
Comment 6 David Strupl 2009-11-13 07:40:53 UTC
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.
Comment 7 Dusan Balek 2009-11-16 08:44:15 UTC
*** Bug 176826 has been marked as a duplicate of this bug. ***
Comment 9 Exceptions Reporter 2009-11-23 19:24:27 UTC
This bug already has 50 duplicates see http://statistics.netbeans.org/exceptions/detail.do?id=154357
Comment 11 Jan Lahoda 2010-05-12 12:25:00 UTC
*** Bug 171436 has been marked as a duplicate of this bug. ***
Comment 12 Jan Lahoda 2010-05-13 09:14:35 UTC
*** Bug 177749 has been marked as a duplicate of this bug. ***
Comment 13 Jaroslav Tulach 2010-06-29 08:48:49 UTC
I just waited 19s after pressing Ctrl-Space. According to UI Responsiveness guidelines, this qualifies for higher priority than P3. Increasing.
Comment 14 Tomas Zezula 2010-06-29 11:23:21 UTC
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.
Comment 15 Dusan Balek 2010-06-29 14:03:15 UTC
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.
Comment 16 Jaroslav Tulach 2010-06-29 16:47:28 UTC
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.
Comment 17 Tomas Zezula 2010-06-29 17:54:05 UTC
>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.
Comment 18 greggwon 2010-06-29 19:20:10 UTC
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.
Comment 19 Jaroslav Tulach 2010-06-30 05:44:27 UTC
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.
Comment 20 Tomas Zezula 2010-06-30 07:10:17 UTC
>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
Comment 21 Tomas Zezula 2010-06-30 08:20:50 UTC
Added dependency on VCS issue (the IO contention case).
Comment 22 Tomas Zezula 2010-06-30 08:22:41 UTC
The biggest problem (calling slow query under lock) is fixed. The rest of problems depends on the issue #186148. Jet-main bcf0fcbbc084
Comment 23 Dusan Balek 2011-10-14 13:27:18 UTC
*** Bug 199718 has been marked as a duplicate of this bug. ***
Comment 24 Dusan Balek 2012-04-23 14:28:16 UTC
*** Bug 176568 has been marked as a duplicate of this bug. ***
Comment 25 Dusan Balek 2012-05-02 13:44:51 UTC
*** Bug 211953 has been marked as a duplicate of this bug. ***
Comment 26 Jaroslav Tulach 2012-05-31 10:10:19 UTC
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)"
Comment 27 Jaroslav Tulach 2012-05-31 10:12:05 UTC
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.
Comment 28 Dusan Balek 2012-06-04 14:31:52 UTC
Fixed in jet-main. http://hg.netbeans.org/jet-main/rev/7e1fd1890078
Comment 29 Quality Engineering 2012-06-08 06:07:26 UTC
Integrated into 'main-golden', will be available in build *201206080001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/7e1fd1890078 User: Dusan Balek <firstname.lastname@example.org> Log: Issue #171183: Code completion substituteText should be done outside of AWT - fixed.