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.
[jdk1.5.0, linux FC2] I have realized that the time to connect to a VM (I am using JPDA & socked connection) varies based on the amount of existing breakpoints set in the code. On my linux box the debugger connect in about 1 second when there is only one one breakpoint. Each next breakpoint adds next ~1second. So when there is about 20 existing breakpoints when attaching to the JVM the connect time is unbearably slow.
This might have a connection with issue #68381. Marek, can you please run the IDE with -J-Dnetbeans.debugger.breakpoints=true and provide the output from console here? We need to compare the difference when there is one and more breakpoints. Thanks.
Created attachment 27502 [details] The debugger log messages for one debugger connect/disconnect
Some more observations: The time necessary to attach to the VM depends on: 1) the number of breakpoints (lets say the time for one breakpoint is X). 2) the number of classes the breakpoins are set in (lets say the time per one class is Y). So then for (values not counted, but approximatelly MEASURED): X=0, Y=0 the AT (attach time) = ~200ms X=1, Y=1 AT = ~500ms X=5, Y=1 AT = ~1500ms X=15, Y=7 AT = ~5000ms => each class prolongs the AT much more than each breakpoint. I hope this will help....
damned, I switched my mind in the middle of writing the report :-). So the X means number of breakpoins and Y number of classes. I am sorry for the confusion.
Thank you for the log and numbers. Starting to work on this...
The performance is bad at two places: 1) In org.netbeans.modules.debugger.projects.EditorContextImpl.getClassName() the Element element = sc.findElement (offset); can take from several hundreds of ms to one second per file. This is out of control of debugger modules. The code retrieves the class name from URL and a line number. 2) In org.netbeans.modules.debugger.jpda.breakpoints.LineBreakpointImpl.classLoaded() we retrieve the location information from the reference type. This takes about a second per one reference type (the time varies a lot). We can not speed up these two bottlenecks, but we can store the class name with the line breakpoint settings. That way we avoid 1) and decrease the CPU consumption to roughly one half. The class name storage is implemented - it has an effect during the second (and all subsequent) start of debugger: /cvs/debuggercore/api/src/org/netbeans/api/debugger/Properties.java,v <-- Properties.java new revision: 1.7; previous revision: 1.6 RCS file: /cvs/debuggerjpda/src/META-INF/debugger/org.netbeans.api.debugger.LazyDebuggerManagerListener,v /cvs/debuggerjpda/src/META-INF/debugger/org.netbeans.api.debugger.LazyDebuggerManagerListener,v <-- org.netbeans.api.debugger.LazyDebuggerManagerListener initial revision: 1.1 RCS file: /cvs/debuggerjpda/src/META-INF/debugger/org.netbeans.api.debugger.Properties$Reader,v /cvs/debuggerjpda/src/META-INF/debugger/org.netbeans.api.debugger.Properties$Reader,v <-- org.netbeans.api.debugger.Properties$Reader initial revision: 1.1 /cvs/debuggerjpda/src/org/netbeans/modules/debugger/jpda/breakpoints/BreakpointImpl.java,v <-- BreakpointImpl.java new revision: 1.23; previous revision: 1.22 /cvs/debuggerjpda/src/org/netbeans/modules/debugger/jpda/breakpoints/BreakpointsEngineListener.java,v <-- BreakpointsEngineListener.java new revision: 1.17; previous revision: 1.16 RCS file: /cvs/debuggerjpda/src/org/netbeans/modules/debugger/jpda/breakpoints/BreakpointsReader.java,v /cvs/debuggerjpda/src/org/netbeans/modules/debugger/jpda/breakpoints/BreakpointsReader.java,v <-- BreakpointsReader.java initial revision: 1.1 /cvs/debuggerjpda/src/org/netbeans/modules/debugger/jpda/breakpoints/ClassBasedBreakpoint.java,v <-- ClassBasedBreakpoint.java new revision: 1.11; previous revision: 1.10 /cvs/debuggerjpda/src/org/netbeans/modules/debugger/jpda/breakpoints/LineBreakpointImpl.java,v <-- LineBreakpointImpl.java new revision: 1.25; previous revision: 1.24 RCS file: /cvs/debuggerjpda/src/org/netbeans/modules/debugger/jpda/breakpoints/PersistenceManager.java,v /cvs/debuggerjpda/src/org/netbeans/modules/debugger/jpda/breakpoints/PersistenceManager.java,v <-- PersistenceManager.java initial revision: 1.1 /cvs/debuggerjpda/src/org/netbeans/modules/debugger/jpda/breakpoints/ThreadBreakpointImpl.java,v <-- ThreadBreakpointImpl.java new revision: 1.6; previous revision: 1.5 /cvs/debuggerjpda/ui/src/META-INF/debugger/org.netbeans.api.debugger.LazyDebuggerManagerListener,v <-- org.netbeans.api.debugger.LazyDebuggerManagerListener new revision: 1.6; previous revision: 1.5 /cvs/debuggerjpda/ui/src/META-INF/debugger/org.netbeans.api.debugger.Properties$Reader,v <-- org.netbeans.api.debugger.Properties$Reader new revision: delete; previous revision: 1.1 /cvs/debuggerjpda/ui/src/org/netbeans/modules/debugger/jpda/ui/PersistenceManager.java,v <-- PersistenceManager.java new revision: delete; previous revision: 1.12 /cvs/debuggerjpda/ui/src/org/netbeans/modules/debugger/jpda/ui/breakpoints/BreakpointsReader.java,v <-- BreakpointsReader.java new revision: delete; previous revision: 1.9
Verified ... and Closing all issues resolved into NetBeans 6.7 and earlier.