Community
Participate
Working Groups
Version: 3.1.0 Build id: 200411170800 When you set a method breakpoint in Class ot ClassLoader the debug target run much slower than when line breakpoints are used. 1. Launch a runtime workbench in debug mode 2. set a method entry breakpoint on ClassLoader.findResources 3. switch back to runtime workbench 4. Open a java editor on a relatively big file. 5. Notice it takes far longer than normal 6. Disable breakpoint and replace with a line breakpoint on the first line of findResources (or any method in the class) 7. Switch back to runtime workbench 8. Notice it seems more responsive Note: The same thing happens (only worse if you put a method breakpoint in Class) I am running on WindowsXP and Sun JDK 1.4.2_02
Needs investigation.
It might be that method tracing is just slow. We'll see if there's anything obvious that we can do better.
When I create a method entry breakpoint the breakpoint performs fine (it is equivalent to a line breakpoint). When I create a entry/exit breakpoint, it is slow. However, in this case, it appears to be a VM limitation. When a method breakpoint is just for entry, we create a line breakpoint under the covers. When it is entry/exit, we create two requests under the covers - one line breakpoint and one method exit request (which appears to perform slow on the target VM). Marking as won't fix, as we have already optimized this one. Please try with the latest integration build, and clarify if you were using entry/exit, or just an entry breakpoint. Thanks.
I was using an entry breakpoint only (i think...). I can confirm I20050405-0800 that the entry only case is now as fast as a line breakpoint. As soon as an exit breakpoint is added the target runs slowly again. Do you have any idea why it slows down only on certain classes? In my case, I don't think any methods in the class with the breakpoint are being accessed. Thanks for making the common case faster. It is a huge improvement.
The entry case is fast if we can determine a fully qualified type name and method signature for the location of the corresponding line breakpoint (which we can for most cases, except when the source you are debugging is external to the Eclipse IDE and is not associated with a Java project, and thus the compiler cannot give us the associated type bindings/qualified names). The method exit case is slow for all cases, as we do not replace with line breakpoints. Instead we use a "method exit" event. It appears that this is just slow on the target VM (I don't know why - it a VM implementation detail). Likewise, if we cannot determine an exact location for the line breakpoint (entry), we rever to a "method entry" event, which also requires tracing and is slow. You should not see this unless you are debugging against "external source". However, this makes me think we could improve method exit breakpoints by determining where the "return" statements are and creating line breakpoints for them, rather than using the "exit" event. I will open a new enhancement request for that.
Hi, I banged my head against this problem for a half-day before finally googling "eclipse breakpoint debug slow" and finding this bug entry! Regarding the comment below that this problem occurs only when "the source you are debugging is external to the Eclipse IDE and is not associated with a Java project", I don't think this is quite right. I encountered the problem with code that is in my workspace (I even did a complete clean and rebuild to make sure everything is ok). I tried to diagnose things further, i.e., to try to figure out which method entry breakpoints are really line breakpoints "under the cover", but could not come up with a clear pattern. It might correlate with methods being protected and/or overidden---it's too hard to diagnose without clear information. On that note, the following CONCRETE PROPOSAL: How about adding a visible property to breakpoints indicating whether they put the VM into tracing mode. E.g., it could say [tracing] in the Breakpoints window, just like it now says [entry]. Even a variation on the icon (something RED :-) to warn the user that the breakpoint will require VM tracing. In most cases, I could just as easily move the breakpoint down a line or two if I knew... Tx, -CR P.S. We really mean SLOW: I am running on a 3.7GHz PC with 2GB of RAM and it ran so slow I kept thinking there was an infinite loop and terminated the execution!
