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.
Summary: | Conditional breakpoints are extremely slow and they (probably) don't need to be | ||
---|---|---|---|
Product: | debugger | Reporter: | _ gtzabari <gtzabari> |
Component: | Java | Assignee: | Martin Entlicher <mentlicher> |
Status: | NEW --- | ||
Severity: | normal | Keywords: | PERFORMANCE |
Priority: | P3 | ||
Version: | 8.2 | ||
Hardware: | PC | ||
OS: | Windows 10 x64 | ||
Issue Type: | ENHANCEMENT | Exception Reporter: |
Description
_ gtzabari
2016-01-02 15:28:36 UTC
To clarify, this isn't a theoretical problem I am complaining about. I am attempting to debug Genetic Algorithms code using conditional breakpoints. The code in question gets invokes tens of millions of times per minute (which is quite normal for Genetic Algorithms) and the resulting performance is extremely bad. If I modify my code and use non-conditional breakpoints, the debugging session flies. Also, I noticed that my code's concurrency drops like a rock (only one CPU core used when using conditional breakpoints and all cores used without them). Do these breakpoints add some sort of locking that would explain this? This is most probably impossible to implement. We can patch a method's bytecode, but the changed method will be executed only after a re-enter of the method. Till the method is re-entered, the old bytecode is being executed. And since main() method is never re-entered, I do not see a way how we could make it work. I'm keeping this as an enhancement though, for that case that https://bugs.openjdk.java.net/browse/JDK-4615046 is implemented. Okay. Ignoring bytecode rewriting for a minute, why are conditional breakpoints so much slower than the rewritten code? |