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.
When a remote application on a different computer is being debugged, the communication with the debugger slows down execution of the application. Even when no breakpoints are active and the application just runs, debugger monitors started and finished threads. It checks their name, state, thread groups, etc. This monitoring slows down application execution, therefore we should try to minimize the communication as much as possible.
Small improvements were made in changeset: 174463:fcd515e6e9b5 http://hg.netbeans.org/main/rev/fcd515e6e9b5
Integrated into 'main-golden', will be available in build *201007180001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/fcd515e6e9b5 User: mentlicher@netbeans.org Log: #188732 Improve performance by caching ability to modify properties and getting rid of unnecessary toString() call on nodes.
Two more improvements were made: changeset: 174615:6ee6c5f2c476 - reduced asking for thread groups changeset: 174617:e1feba92215a - Do not try to annotate threads that are not suspended.
The performance should be visibly better now. We can further improve performance when some threads are being suspended by better caching of stack frames in JPDAThreadImpl.getCallStack(). But that is more a subject of issue #57410. Marking as fixed, Yarda can you verify?
Integrated into 'main-golden', will be available in build *201007230001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/6ee6c5f2c476 User: mentlicher@netbeans.org Log: #188732 Prevent from asking for thread groups when thread groups are not being displayed in the UI.
JDK 7 has a better caching mechanism of stack frames in JDI layer. Therefore when debugger (NetBeans) runs on JDK 7, the performance should be further improved by stack frame caching.
Did you try that? I am using NetBeans IDE Dev (Build 100728-5a8de25edeed) and the execution is still horribly slow.
I have breakpoint at org.netbeans.core.startup.ModuleSystem:122 and (althrough this is a code which usually gets executed during first second), I was waiting for 2.5min to reach that breakpoint.
Integrated into 'main-golden', will be available in build *201007290001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/dfccc159581f User: mentlicher@netbeans.org Log: #187533, #188732 Cache the thread stack depth and assure that stack frames are retrieved only for suspended threads (thus preventing from IncompatibleThreadStateException. Also suspendedNoFire is set to false when a thread is resumed. This should also prevent from bug #141061.
I've just tried to debug the same application under Eclipse. Works quite fine in spite of the TCP distance.
Then the problem is likely http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6457137
IMHO the best would be to do the fix in the JDI implementation, where the problem is. This is a part of JDK, not NetBeans.
We have provided patch to http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6457137 We're clear that we do not want to make a NetBeans-specific copy of JDI implementation. Therefore the problem with class prepare traffic needs to be fixed in the JDK. Since the other NetBeans-related issues were resolved, I'm resolving this as fixed.