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.
Improve the behaviour of the JCC. It have following problems (with possible solutions): *) Moves/resizes as user type, if shown (too much visual noise) - once shown (using some more reasonable placement/sizing), maintain the position/size. *) JavaDoc redraws even with no change (user types one more letter or moves caret, not actually changing the selection in list, but the JD window shows "Searching", computes the same value again and then redisplays it. - Keep reference to the last list selection and redisplay JavaDoc only on _real_ change. *) "Searching..." is actually displayed/layouted twice because of two events. - Take care of caret event after modify event! Once this is all in place, it may be possible to aim for faster live updates during typing: 1. Start background processing immediatelly, not delayed. (needs faster updates of the list because it would happen more frequently). 2. If possible, be able to do subqueries, not full queries (it would speed up querying significantly, because next typed letter is mostly just a simple filtering pass) Ad 2) It should be possible! Explorer can keep scrolling with me typing the file name into fast-locate box. Now, I have some of this as a proof of concept already on my HDD, so if you need some help...
OK. Note, that there are another potential performance issues you should know about: 1. Please, check performance impact of the implemented feature - issue #23467 also. 2. issue #28393
Issue 23467 should not be a problem, JavaDoc is slow already and we may be able to make JavaDoc-from-JavaDoc even faster than JavaDoc-from-source. In this stage I'm mostly interrested in fast completion feedback. Ad issue 28393: I think they're off track. I should add some comments there. Anyway, for us, it means we should try to do less thread switches during computations as they can insert random delays into the critical path. I'll lok into this more. For now, I'm profiling the completion code and it seems we have some headroom there as well.
I have some measurement results: Backgroud completion updates are two-fold: 1. query execution 2. update of the completion window 1) runs in background and generally does not influence UI responsiveness much, but it still influences latency tonew results. 2) runs in AWT so it must be very fast to not slow down typing It seems that in 2), there is too much work done currently - it reinstalls the view into the editor's popup pane, which causes some validation and so on. It seems it is sufficient to just replace the model of the completion list. It makes a difference like 20ms vs. 2ms I'll keep working on the query part (1).
Some more observations: There are many background tasks performed on document modification and /or cursor movement: *) Position status update *) Error annotations *) src-hierarchy update *) undo/redo action state update *) completion update *) ... They are all somehow delayed, but there is no coordination among them. Some are posted to RP, some are posted using Swing Timer, there is some rescheduling back and forth. The net effect is that some of them are running in paralel fighting for cpu and/or wait for timeslice. (e.g. completion only: AWT, RP, source parsing RP). Also, each scheduling request have to wake up some thread and that thread have to do something (compute the new sleep value, go to sleep again), so we have big context switching rate. The context switching may or may not itself be a problem, but having too many contex switches on the critical path means starvation when something runs in background at that time. This is one of the problems of the completion (simpler case): *) AWT: Notified about doc change, reshedules itself to end of AWTQ *) AWT: Post QueryTask and WaitTask to RP *) RP: invoke prepare-parsing (JavaParser thread started, this is a clash with src-hierarchy update: It is meant to be updated after 2000ms, but completion invokes it immediatelly, which in turn causes drawing the error annotation too early (competition between AWT and the query processing)). In RP, completion computations continue. Once done (if not slower than 100ms) it cancels WaitTask and reschedule to AWTQ. *) AWT: set the result, plan the repaint, do the repaint Now, this looks quite good except for the races with java parser thread and induced AWT repaints. Not talking about other tasks that may interrupt it. But finally, the timing of the updates is quite undeterministic. E.g. the paralel reparse is likely to produce a lot of garbage ind induce small gc (In my test case 1MB of garbage per invocation, minor gc (50ms) on every other invocation). It would be nice if we could somehow coordinate the background work to not pop up at inconvenient times. It would be nice if we could selectively skip calling java parser (Oh, I've just added another letter, no member changed!)
Petre, many thanks for the analysis. There were many bugfixes and other changes done to completion code so it looks somewhat blurry now. Anyway me and Mato will try to sketch the process of invoking/refreshing of the completion and eliminate extra unnecessary steps and refactor the code. Regarding your last comment I think that there could be certain low-cost improvements done e.g. when we are just extending the identifier by typing we could eliminate reparsing as you've suggested. Not sure whether that could be checked easily with the current lexing mechanism but it can be done easily once the lexer module will be used.
fixed in [maintrunk] Petr, thanks for your help and ideas. I hope, that I fixed all that you mentioned. :-) If not, please reopen... /cvs/editor/libsrc/org/netbeans/editor/ext/Completion.java,v <-- Completion.java new revision: 1.29; previous revision: 1.28 /cvs/editor/libsrc/org/netbeans/editor/ext/CompletionJavaDoc.java,v <-- CompletionJavaDoc.java new revision: 1.22; previous revision: 1.21 /cvs/editor/libsrc/org/netbeans/editor/ext/JDCPopupPanel.java,v <-- JDCPopupPanel.java new revision: 1.18; previous revision: 1.17 /cvs/editor/src/org/netbeans/modules/editor/java/NbJavaSyntaxSupport.java,v <-- NbJavaSyntaxSupport.java new revision: 1.46; previous revision: 1.45
fixed in [prj40_prototype] /cvs/editor/libsrc/org/netbeans/editor/ext/Completion.java,v <-- Completion.java new revision: 1.21.10.4; previous revision: 1.21.10.3 /cvs/editor/libsrc/org/netbeans/editor/ext/CompletionJavaDoc.java,v <-- CompletionJavaDoc.java new revision: 1.12.46.3.2.4; previous revision: 1.12.46.3.2.3 /cvs/editor/libsrc/org/netbeans/editor/ext/JDCPopupPanel.java,v <-- JDCPopupPanel.java new revision: 1.13.28.1.2.3; previous revision: 1.13.28.1.2.2 /cvs/java/editor/src/org/netbeans/modules/editor/java/Attic/NbJavaSyntaxSupport.java,v <-- NbJavaSyntaxSupport.java new revision: 1.1.2.1.2.1.2.10; previous revision: 1.1.2.1.2.1.2.9
Petre, could you please verify this issue? I've looked at it and IMO it seems to be updated/fixed well.
Old issue -> marking as verified.