Version: 3.4 (using KDE KDE 3.5.6) Installed from: Compiled From Sources OS: Linux The step over function in the debugger is currently too slow to be useful, it takes several seconds on my machine. When stepping over, the debugger does the following: -exec-next -file-list-exec-source-file -break-list -thread-list-ids -stack-info-depth 6 -stack-list-frames 0 5 I only see -exec-next as necessary. -file-list-exec-source-file seems to return the current file and line. However this is also returned be -exec-next, so why is this needed? -break-list probably updates the list of breakpoints. Why is this done? Does this really need to be done if the breakpoint widget is not shown currently? -thread-list-ids, -stack-info-depth 6 and -stack-list-frames 0 5 probably update the framestack widget. Again, is this also necessary when the framestack widget is not shown?
I might be wrong, but the widgets don't know wether they are currently shown or not. So updating the framestack needs to be done. Apart from this bugreport you probably should also file a couple of BR's against gdb, because its slow like hell for no particular reason (I created profiling information for Vladimir and he couldn't understand why the most-called-functions are called that often).
> I might be wrong, but the widgets don't know wether they are currently > shown or not. I hope this can be changed then. > Apart from this bugreport you probably should also file a couple of BR's > against gdb. Hmm, I have taken a quick look at the GDB reports and they seem very technical. Do you think I can really file a report which basically says "These commands are too slow"? > because its slow like hell for no particular reason (I created > profiling information for Vladimir and he couldn't understand why the > most-called-functions are called that often). I'm just curious: How did you create the profiling information? Is Vladimir still active in KDevelop/GDB development (haven't seen many commits lately).
> > I might be wrong, but the widgets don't know wether they are currently > > shown or not. > > I hope this can be changed then. I don't know wether it can be changed. I only had short looks into the debugger and its not really appealling to work on the code. > > Apart from this bugreport you probably should also file a couple of BR's > > against gdb. > > Hmm, I have taken a quick look at the GDB reports and they seem very > technical. Do you think I can really file a report which basically > says "These commands are too slow"? I guess you should have at least some profiling information > > because its slow like hell for no particular reason (I created > > profiling information for Vladimir and he couldn't understand why the > > most-called-functions are called that often). > > I'm just curious: How did you create the profiling information? Is Vladimir > still active in KDevelop/GDB development (haven't seen many commits lately). He's on IRC quite often although he seems to lack time for KDevelop hacking. As far as generating the profiling information, I don't know exactly, but first thing was to build gdb with profiling support enabled. Then use a gdb command to enable profiling (maint set profile) before running the application and then run gprof over the created output. The output of that is then human readable.
Created attachment 20231 [details] Patch which does not update framestack widget
Comment on attachment 20231 [details] Patch which does not update framestack widget OK, I've commited that patch now.
Created attachment 20236 [details] This disabled updates to the breakpoint widget when it is hidden Basically the same as the patch for the framestack widget. I noticed one bug though: When inserting a breakpoint manually with a GDB command, it not shown directly (old bug, see bug 118327). However, this patch makes the situation a bit worse: When hitting that breakpoint, it is still not displayed in the editor, until switching to the breakpoint widget. The proper fix would be to somehow notify the breakpoint widget when the user manually inserts a breakpoint. Although I tested the patch a bit, I still do not trust it completely, there might be other side-effect of the widget's breakpoint getting out of sync with GDB's breakpoints.
Hmmm, the breakpoint patch is wrong anyway because it can send commands to the debugger when it is not running. I guess the framestack patch is OK because the framestack is only shown when the debugger is running (I hope).
SVN commit 655835 by tmcguire: Revert my commit 652655. This needs a more sophisticated approach. Current problems: - Sometimes the framestack widget is shown when the debugger is not running, then tries to update which will not work and show an error message - The framestack widget is sometimes updated even when the program state did not change, for example when switching tabs. This causes the widget to be reset, which will lose all custom expanded frames. CCBUG: 143977 M +0 -17 framestackwidget.cpp M +0 -1 framestackwidget.h --- branches/KDE/3.5/kdevelop/languages/cpp/debugger/framestackwidget.cpp #655834:655835 @@ -128,12 +128,6 @@ void FramestackWidget::slotEvent(GDBController::event_t e) { - //We do not update the frame stack widget if it is not visible. - //This saves some time when stepping in/over, as unnecessary - //GDB commands are avoided. - if (!isVisible()) - return; - switch(e) { case GDBController::program_state_changed: @@ -473,17 +467,6 @@ p->fillRect(section1, KGlobalSettings::alternateBackgroundColor()); } - -void FramestackWidget::showEvent ( QShowEvent *event ) -{ - QListView::showEvent( event ); - - //Because this widget was hidden before, its state is out of date. - //Force an update by sending the appropriate events. - slotEvent( GDBController::program_state_changed ); - slotEvent( GDBController::thread_or_frame_changed ); -} - // ************************************************************************** // ************************************************************************** // ************************************************************************** --- branches/KDE/3.5/kdevelop/languages/cpp/debugger/framestackwidget.h #655834:655835 @@ -112,7 +112,6 @@ void drawContentsOffset( QPainter * p, int ox, int oy, int cx, int cy, int cw, int ch ); - void showEvent ( QShowEvent *event ); private:
*** Bug 147607 has been marked as a duplicate of this bug. ***
Note that the duplicate report also has a very similar patch. How is the stepping speed in KDevelop4?
The patch for bug 147607 is similar to this one but it does not have the problems described in comment #8.
This issue has been solved in trunk. If you close the stack view + the variable view they won't get any updates. -break-list will stay because: * it's fast * breakpoint states will be shown in the editor, even if the view is closed