Created attachment 141617 [details]
in-place renaming self-profile

self-profiling!

Please, do not use instance rename for renaming 134 occurrences.
Use rename refactoring instead.
I do not see problem in your snapshot.
Please provide more precise definition of "each typed symbol is appearing only after a while". (for example: typing of 10 symbols in instance rename field is consumed 20 seconds).

(In reply to Alexander Simon from comment #2)
> Please, do not use instance rename for renaming 134 occurrences.
> Use rename refactoring instead.
It is a local variable. I press Ctrl-R and IDE does what it does - in-place rename.

> I do not see problem in your snapshot.
> Please provide more precise definition of "each typed symbol is appearing
> only after a while". (for example: typing of 10 symbols in instance rename
> field is consumed 20 seconds).
Please, follow instructions to get openJDK project
http://netbeans.dzone.com/articles/hack-openjdk-netbeans-ide
Open file 
../jdk/hotspot/src/share/vm/utilities/vmError.cpp
and try to reproduce.
I think we found the excellent corner case which demonstrates issue with IDE responsiveness. Fixing it would allow to make IDE faster.
Thanks for understanding.

Btw, probably the issue is with our impl of editable regions. Does java has different impl? (at least they have visually different in-place rename regions)

(In reply to Vladimir Voskresensky from comment #4)
> Btw, probably the issue is with our impl of editable regions. Does java has
> different impl? (at least they have visually different in-place rename
> regions)
It is an editor problem.
Try to simple java application with method:

private static int foo(int st) {
  st = st + st * 3 + st * 4 + st * 5;
  st = st + st * 3 + st * 4 + st * 5;
.... (repeat 50 times)
  st = st + st * 3 + st * 4 + st * 5;
  return st;
}

Try to instance rename of st.
Main problem is:
- editor notified all listeners about changes while typing in instance rename field. For example EDT paints 900 ms and listeners works 2500 ms in EDT.

Vladimir, could you conform the problem in java (see my example in previous comment)?

Yes, I can confirm. In Java it is as very slow as in C++. Probably you are right and it's the editor issue.

Btw, in Java there are also a lot of exceptions in console:
INFO [org.netbeans.spi.lexer.MutableTextInput]: !!WARNING!! Missing READ-LOCK when accessing TokenHierarchy: input-source:org.netbeans.modules.editor.NbEditorDocument@981b4c8, mimeType='text/x-java', kitClass=null, length=1873, version=906, file=org.netbeans.modules.java.JavaDataObject@42fc0dd4[/home/vv159170/NetBeansProjects/JavaApplication1/src/javaapplication1/JavaApplication1.java@4c0fead3:6964c078]
java.lang.Exception
	at org.netbeans.lib.lexer.TokenHierarchyOperation.ensureReadLocked(TokenHierarchyOperation.java:398)
	at org.netbeans.lib.lexer.TokenHierarchyOperation.tokenSequence(TokenHierarchyOperation.java:423)
	at org.netbeans.lib.lexer.TokenHierarchyOperation.tokenSequence(TokenHierarchyOperation.java:419)
	at org.netbeans.api.lexer.TokenHierarchy.tokenSequence(TokenHierarchy.java:186)
	at org.netbeans.modules.javadoc.highlighting.Highlighting$HSImpl.moveNext(Highlighting.java:210)
	at org.netbeans.modules.editor.lib2.highlighting.DirectMergeContainer$Wrapper.fetchNextHighlight(DirectMergeContainer.java:443)
	at org.netbeans.modules.editor.lib2.highlighting.DirectMergeContainer$Wrapper.<init>(DirectMergeContainer.java:408)
	at org.netbeans.modules.editor.lib2.highlighting.DirectMergeContainer$HlSequence.<init>(DirectMergeContainer.java:198)
	at org.netbeans.modules.editor.lib2.highlighting.DirectMergeContainer.getHighlights(DirectMergeContainer.java:104)
	at org.netbeans.modules.editor.lib2.highlighting.HighlightsReader.<init>(HighlightsReader.java:62)
	at org.netbeans.modules.editor.lib2.view.HighlightsViewFactory.restart(HighlightsViewFactory.java:201)
	at org.netbeans.modules.editor.lib2.view.ViewBuilder$FactoryState.init(ViewBuilder.java:1324)
	at org.netbeans.modules.editor.lib2.view.ViewBuilder.createViews(ViewBuilder.java:724)
	at org.netbeans.modules.editor.lib2.view.ViewBuilder.createReplaceRepaintViews(ViewBuilder.java:685)
	at org.netbeans.modules.editor.lib2.view.ViewUpdates.reinitAllViews(ViewUpdates.java:206)
	at org.netbeans.modules.editor.lib2.view.DocumentViewOp.checkViewsInited(DocumentViewOp.java:539)
	at org.netbeans.modules.editor.lib2.view.DocumentView.modelToYNeedsLock(DocumentView.java:787)
	at org.netbeans.modules.editor.lib2.view.ViewHierarchyImpl.modelToY(ViewHierarchyImpl.java:208)
	at org.netbeans.modules.editor.lib2.view.LockedViewHierarchy.modelToY(LockedViewHierarchy.java:108)
	at org.netbeans.editor.BaseTextUI.getYFromPos(BaseTextUI.java:291)
	at org.netbeans.modules.editor.bracesmatching.BraceMatchingSidebarComponent.showTooltip(BraceMatchingSidebarComponent.java:686)
	at org.netbeans.modules.editor.bracesmatching.BraceMatchingSidebarComponent.access$500(BraceMatchingSidebarComponent.java:112)
	at org.netbeans.modules.editor.bracesmatching.BraceMatchingSidebarComponent$5.run(BraceMatchingSidebarComponent.java:450)
	at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:251)
	at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:733)
	at java.awt.EventQueue.access$200(EventQueue.java:103)
	at java.awt.EventQueue$3.run(EventQueue.java:694)
	at java.awt.EventQueue$3.run(EventQueue.java:692)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76)
	at java.awt.EventQueue.dispatchEvent(EventQueue.java:703)
	at org.netbeans.core.TimableEventQueue.dispatchEvent(TimableEventQueue.java:159)
	at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:242)
	at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:161)
	at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:146)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:138)
	at java.awt.EventDispatchThread.run(EventDispatchThread.java:91)

Mila, can we do something to speed up in-place renames?

Created attachment 141743 [details]
java app to see very slow painting of typed symbol

use this java app and start in-place rename for "st" variable

Created attachment 141744 [details]
Speedup in 2 times

Patch reduce number of document insert/remove events.
Can be applied to CND and Java SyncDocumentRegion.

Hotspot is Task.schedule(int delay) (26%)

It can be easy fixed in clients.
For example:
        if (task.getDelay() < delay - 100) {
            task.schedule(delay);
        }

Alexander, could you, please, patch CDN impl and I will check the effect. Thanks

(In reply to Vladimir Voskresensky from comment #12)
> Alexander, could you, please, patch CDN impl and I will check the effect.
> Thanks
Done:
4d8cc4f0566c - reduce number of document insert/remove events
13594116b886 - reduce number schedule events in cnd parsing

Created attachment 141763 [details]
profiling result of in-place rename

Created attachment 141764 [details]
back traces of the hotspot

Integrated into 'releases/release74', will be available in build *201311111738* or newer. Wait for official and publicly available build.

Changeset: http://hg.netbeans.org/releases/rev/45607112055a
User: Alexander Simon <alexvsimon@netbeans.org>
Log: some improvement for Bug #237734 very slow Ctrl+R in-place renaming
(transplanted from c7fcf016ae0d494aa5c40d2eed131a48c17ce67b)

I have applied Alexander's patch 4d8cc4f0566c into codetemplates infrastructure and java.
http://hg.netbeans.org/jet-main/rev/6eb1023dd474


When writing DocumentListener implementations we should always consider whether the same task could be accomplished by AtomicListener which would only be triggered once.