Community
Participate
Working Groups
Build 20021029 (and 20021022) I'm trying to debug Eclipse's Ant core, but it takes me more than 2 seconds for each step. 1. Place a breakpoint in AntRunner.getAvailableTargets(). 2. Debug to the breakpoint and try to step a few times. 3. The step takes more than 2 seconds, during which my CPU is pegged at 100%. This happens for all steps, even stepping over the following: List infos= (List) results;
The problem only occurs with Step Over.
Need to address if this is still an issue.
*** Bug 26973 has been marked as a duplicate of this bug. ***
(performance issue)
This is definitely an issue. I have a very fast machine (dual 2.4GHz), but stepping is still over a second. While stepping, there is a LOT of redraw activity going on in the stack trace window. This is with the latest M3 build. Step-into is just as slow when not descending into a subroutine. JDK is IBM 1.3.1, platform is RH8.0
An important thing to mention is that the views (debug view, variables view, etc.) update immediately. It seems to be the editor that is lagging behind. Could this be related to the instruction pointer?
Do you still see this issue with the latest build (20021119) ? It is certainly still possible to increase the performance, but I no more get the "> 2 seconds" problem.
I20021119 won't run for me, so I can't test the stepping. When trying to launch, I get: java.lang.NoClassDefFoundError: org/eclipse/swt/widgets/Widget
I20021119 still has the exact same behavior. 1 second per step-over.
I filled a bug against GTK (bug 27862).
The root of the problem in our code is in LaunchViewEventHandler#handleSuspendThreadEvent(...). This method tries to be clever about only refreshing the tree, but it looks like our efforts are just slowing things down. Currently, the method says that if the number of stack frames has changed (as in a StepIn or StepReturn), we refresh the entire thread. If the number of frames hasn't changed (as in a StepOver), we refresh each stack frame instead. This code (refreshing each stack frame individually) is the problem. As explained in Bug 27862, this causes setSelection() to be called for each stack frame. On GTK, setSelection() is apparently very slow. The GTK bug needs to be addressed by the SWT team, but I think we should also reexamine our "clever" code in the event handler. We're doing a lot of work to figure out which frames need to be refreshed. If this code is hurting performance significantly (and it is), we should yank it.
Fixed. By removing our witty code, stepping performance has been improved dramatically. Please verify.
Verified. Stepping is much faster.
I also verify that stepping is much improved. There is still a visible lag but not much.
