This bug was originally marked as duplicate of bug 181584, that is already resolved. This bug is still valid, so this seems to be another bug, but it might be related.
Build: NetBeans IDE Dev (Build 110111-15d18b8a60bf)
VM: Java HotSpot(TM) Client VM, 19.0-b09, Java(TM) SE Runtime Environment, 1.6.0_23-b05
hmichel: Doing a Replace All operation. I removed all white spaces just replacing them by no character
Maximum slowness yet reported was 27031 ms, average is 27031
Created attachment 104896 [details]
fixed versioning part: http://hg.netbeans.org/core-main/rev/2aff3af041c8
passing to the owner of another blocking code
The three biggest contributors to the slowness are DiffSideBar, ComponentPeer and TodoAnnotationProvider, and in all cases the time is spent almost solely in RequestProcessor$Task.schedule, mostly in construction of the debugging stacktrace. Typically we handle such reports by disabling the stack traces for the given RP (I did that myself several times already). While I understand that the stack trace may be useful for debugging in some cases, I wonder if this approach is correct: as we disable the stack traces, the usefulness of the debugging code is vanishing as less and less RPs use it. (Note that even if the stack traces are taken only with assertions enabled, bug reports like this one count and need to be evaluated as any other bug report.) Basically, the question is whether we:
1. try to make the debugging code less intrusive, even at the cost of making it less useful. E.g. by enabling it only when a specific command line is given, or by using some other heuristic described in:
2. continue with our current approach, making the debugging code completely irrelevant eventually
If the choice is 2, please pass this bug back to me, I will disable the creation of stack traces in places that I maintain.
Integrated into 'main-golden', will be available in build *201101130001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
User: Ondrej Vrabec <email@example.com>
Log: Issue #194234 - [70cat] LowPerformance took 27031 ms
No new duplicate reports since the fix. Closing.