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.

Bug 194234 - [70cat] LowPerformance took 27031 ms.
Summary: [70cat] LowPerformance took 27031 ms.
Status: RESOLVED FIXED
Alias: None
Product: platform
Classification: Unclassified
Component: -- Other -- (show other bugs)
Version: 6.x
Hardware: All All
: P3 normal (vote)
Assignee: Antonin Nebuzelsky
URL:
Keywords: PERFORMANCE
Depends on:
Blocks:
 
Reported: 2011-01-11 23:20 UTC by Michel Graciano
Modified: 2011-10-05 20:27 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter: 175756


Attachments
nps snapshot (13.41 KB, application/nps)
2011-01-11 23:21 UTC, Michel Graciano
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Michel Graciano 2011-01-11 23:20:57 UTC
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
OS: Linux

User Comments:
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
Comment 1 Michel Graciano 2011-01-11 23:21:04 UTC
Created attachment 104896 [details]
nps snapshot
Comment 2 Ondrej Vrabec 2011-01-12 10:56:52 UTC
fixed versioning part: http://hg.netbeans.org/core-main/rev/2aff3af041c8
passing to the owner of another blocking code
Comment 3 Jan Lahoda 2011-01-12 13:10:14 UTC
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:
http://netbeans.org/bugzilla/show_bug.cgi?id=165862#c8
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.
Comment 4 Quality Engineering 2011-01-13 07:51:07 UTC
Integrated into 'main-golden', will be available in build *201101130001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/2aff3af041c8
User: Ondrej Vrabec <ovrabec@netbeans.org>
Log: Issue #194234 - [70cat] LowPerformance took 27031 ms
Comment 5 Antonin Nebuzelsky 2011-10-05 20:27:08 UTC
No new duplicate reports since the fix. Closing.