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.
Intel 700MHz; enough memory; win 2000; jdk 131; Pilsen; tomcat 32 - simple JSP - JSP debugging - Step Over - about 1 second Orion; tomcat 40 - JSP debugging - Step Over - about 4 seconds Ideal time: about 0.1 .. 0.4 second The performance proccess document should be updated
if you debug a java code (for example a bean in a JSP) the time is same
Created attachment 4686 [details] analysis from the optimizeIt
Created attachment 4687 [details] analysis from the optimizeIt
every F8 is Utils.getLineSet calls 44 times. 3 times for current debugging class 41 times for callStack java.lang.Exception: Stack trace at java.lang.Thread.dumpStack(Thread.java:1071) at org.netbeans.modules.debugger.support.util.Utils.getLineSet (Utils.java:486) at org.netbeans.modules.debugger.support.util.Utils.getLine (Utils.java:468) at org.netbeans.modules.debugger.support.util.Utils.getLine (Utils.java:559) at org.netbeans.modules.debugger.support.util.Utils.getLineForSource (Utils.java:457) at org.netbeans.modules.debugger.support.java.CallStackFrame.getLine (CallStackFrame.java:94) at org.netbeans.modules.debugger.support.java.JavaDebugger.annotateCallSt ack(JavaDebugger.java:303) at org.netbeans.modules.debugger.support.java.JavaThread.setCurrent (JavaThread.java:163) at org.netbeans.modules.debugger.jpda.JPDADebugger.makeCurrent (JPDADebugger.java:932) at org.netbeans.modules.debugger.jpda.JPDADebugger.exec (JPDADebugger.java:692) at org.netbeans.modules.debugger.jpda.util.Operator$1.run (Operator.java:104) at java.lang.Thread.run(Thread.java:536)
so there are two problems: 1) do we need to find line for every thread in call stack 2) why is proxyLoader so slow
This is a serious performance problem, but the IDE is still nornally usable -> downgrading to P2.
I've looked at the dumps re. ProxyClassLoader and the problem is that it delegates to too many other classloaders (repository, libraries, system CL). The culprit is ClassElement, which uses currentClassLoader thus looking up in all the modules (probably not the intended behaviour). In fact, the slow part is execution.NbClassLoader. Moreover, >80% of time spent in the ClassLoader is spent in java.lang.Package.getSystemPackage() because it gets there too often (probably from every module CL). Call counts will tell more, can you try instrumenting profiler on this please?
*** This issue has been marked as a duplicate of 20753 ***
I would prefer if we first verified that this indeed is a duplicate and that fix for 20753 fixes this. So "depends on" relationship is more appropriate.
ok, we will wait for 20753 integration into the maintrunk
mistake: into the orion_fcs
in the orion fcs
verified in the orion fcs
3.3.2_CANDIDATE keyword removed, as no changes beyond fixing 20753 are needed.
Changing target milestone to FFJ 4.0
Resolved for 3.4.x or earlier, no new info since then -> closing.