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.
Beginning of action: Press keyboard key Completion: Character appears in editor Maximum time allowed: 100 ms
Hi, do you have any clue that this takes *more* than 100ms? Please, note this: 1. The machine tested (processor, frequency, memory (RAM), OS, JDK version) will make big difference. 2. There are some freezes during typing, but these are caused by garbage collector. I am not aware about any way that editor itself can prevent this. Please, provide more info about where it tooke more that 100ms, and why.
Every keystroke in java editor launches background operation (batched): 100ms looking for matching bracket 200ms updating caret position 1000ms updating toolbar combo setSelectedNode() -> 200ms property sheet update These operations must be checked for garbage production.
Created attachment 7826 [details] Profile: auto completion initializes JDP too early
Created attachment 7827 [details] Profile: auto completion initializes JDP too early
Created attachment 7828 [details] A fix that lazy initializes JDP
Eliminating issue 13768 will help in autocompletion check case.
I instrumented Completion class and observed four completion events per typed character: ENTRY insertUpdate ENTRY completionCancel ENTRY caretUpdate ENTRY cancelRequest quite complicated... I'll simplify it.
completionCancel call eliminated by adding a fast check to CompletionJavaDoc caret listener implementation.
Marian's measurement (time in milliseconds): conditions: - SUN UltraSparc60 / 512 MB RAM / Solaris 5.8 / CDE - JDK1.4.1(01) - [nb_dev](200211140100) , MDI - mounted sampledir type a character in the editor 12 9 20 Test cases described on page : http://performance.netbeans.org/qa/TestSuites.html#type_a_character_in_editor
Not sure how to measure this - if such simple and isolated measuring is enough...
Created attachment 8118 [details] Synchronous document listener consequence
DocumentListener JavaDoc: The DocumentEvent notification is based upon the JavaBeans event model. There is no guarantee about the order of delivery to listeners, and all listeners must be notified prior to making further mutations to the Document. This means implementations of the DocumentListener may not mutate the source of the event (i.e. the associated Document). It means that keytyping may be blocked by any handler. Unfortunatelly handlers are unknown to editor module. Expensive handler of keytype DocumentEvent is attached.
Tim could you add -J-XX:+UseConcMarkSweepGC to core/release/ide.cfg. AFAIK we concluded that it is harmless for old JVMs. On recent JVMs it solves latency problems (that hurts editor a lot).
Does not seem to be harmless. JVM crashes with -J-XX:+UseConcMarkSweepGC on JDK 1.4.0 on my machine (Win2K).
All of the measurements I made back in the fall showed UseConcMarkSweepGC to be considerably slower, and I've also had stability problems when using it.
Considerably slower? Does it influenced responsiveness? Is it too intrusive? I have possitive experience with it on Linux -Xverbose:gc showed that it never blocks JVM in stop the world manner for more than 200ms comparing to default 700ms-15000ms.
Adding Dafe to cc list, since I know he had some problems with this setting too. My experience with it on Solaris was that the IDE was nearly unusably slow.
Another negative experience from mailing list: Thomas Kellerer <spam_eater@gmx.net> wrote: Keep an eye on your memory consumption. With W2K and JDK 1.4.1 this option sharply increased NB's memory consumption so I stopped using it (about 400MB after 1-2 hours, without that option it's about 100MB after that time). Does 1.4.2 address it?
It's a kind of umbrella issue. Targeted to >=M3.
We did what we did ... closing as fixed. Please eneter separate issues if some problem remain.