bug#11265: 24.0.94; gdb-mi very slow on Windows

bug#11265: 24.0.94; gdb-mi very slow on Windows

[Karl-Heinz Schneider]

I use Emacs for C/C++ development on Windows XP. Since update to Emacs
24.0.94 I discovered that debugging with gdb-mi is very slow.

Right after starting debugging performance is ok, but after a while
using the debugger (adding breakpoints, removing breakpoints setting
conditions, etc...) becomes very very slow.

After a while Emacs is consuming 100% of CPU power for a while just
for typing a single character into the gdb-buffer (not sending it to 
GDB).
GDB commands like "next" or "step" take then several seconds until
all buffers are refreshed.

bug#11265: 24.0.94; gdb-mi very slow on Windows

[Eli Zaretskii]

> Date: Tue, 17 Apr 2012 16:21:05 +0200
> From: Karl-Heinz Schneider <karl-heinz@schneider-inet.de>
> 
> I use Emacs for C/C++ development on Windows XP. Since update to Emacs
> 24.0.94 I discovered that debugging with gdb-mi is very slow.

Which version did you upgrade from?  IOW, with which version are you
comparing the speed?

> Right after starting debugging performance is ok, but after a while
> using the debugger (adding breakpoints, removing breakpoints setting
> conditions, etc...) becomes very very slow.
> 
> After a while Emacs is consuming 100% of CPU power for a while just
> for typing a single character into the gdb-buffer (not sending it to 
> GDB).
> GDB commands like "next" or "step" take then several seconds until
> all buffers are refreshed.

When this slowdown happens, is the GDB interaction buffer displayed?
If so, does it help to delete the window where the interaction buffer
is shown, so that the buffer is not displayed in any window?

(I'm trying to establish whether the slowness is related to display or
to something else.)

Another thing to try is start GDB like this:

  M-x gud-gdb RET

and see if the resulting session is as fast as what you were used to
before 24.0.94.

bug#11265: 24.0.94; gdb-mi very slow on Windows

[Chong Yidong]

> When this slowdown happens, is the GDB interaction buffer displayed?
> If so, does it help to delete the window where the interaction buffer
> is shown, so that the buffer is not displayed in any window?
>
> Another thing to try is start GDB like this:
>
>   M-x gud-gdb RET
>
> and see if the resulting session is as fast as what you were used to
> before 24.0.94.

In addition to what Eli suggested, try setting bidi-paragraph-direction
to 'left in the *gud* buffer and see if it makes a difference in speed.

bug#11265: 24.0.94; gdb-mi very slow on Windows

[Eli Zaretskii]

> From: Chong Yidong <cyd@gnu.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,  11265@debbugs.gnu.org
> Date: Wed, 18 Apr 2012 09:56:37 +0800
> 
> In addition to what Eli suggested, try setting bidi-paragraph-direction
> to 'left in the *gud* buffer and see if it makes a difference in speed.

I doubt that this could be related, since each time you type
"continue" in the gud buffer, there's an empty line after the
"Continuing" response.

Anyway, I did a long debugging session, got to about 1000 lines in the
gud buffer, but didn't see any perceptible slowdown.  So the reason is
still unclear.

bug#11265: 24.0.94; gdb-mi very slow on Windows

[Eli Zaretskii]

[Please keep the bug address on the CC list, so that this whole
discussion gets archived.]

> Date: Wed, 18 Apr 2012 08:53:16 +0200
> From: Karl-Heinz Schneider <karl-heinz@schneider-inet.de>
> 
> I discovered that the slowdown happens after restarting the process to 
> debug.
> I did the following procedure:
> 
> 1. Start the debugger (with process cmd-line).
> 2. Enter run to start the process
> 3. Debug the process
> 4. Enter kill to stop the process
> 5. Change code and recompile
> 6. Start again with step 2
> 
> Doing this three or four times debugging starts to get slow.

If you omit step 5, does the problem still happen?

> All debugging is done within the gud buffer using GDB commands.

If, instead of stopping the process in step 4, you kill the gud buffer
through which you interact with GDB, do you still see the slowdown
after several times that you kill and restart the debugging?

bug#11265: 24.0.94; gdb-mi very slow on Windows

[Karl-Heinz Schneider]

>> I discovered that the slowdown happens after restarting the process 
>> to
>> debug.
>> I did the following procedure:
>>
>> 1. Start the debugger (with process cmd-line).
>> 2. Enter run to start the process
>> 3. Debug the process
>> 4. Enter kill to stop the process
>> 5. Change code and recompile
>> 6. Start again with step 2
>>
>> Doing this three or four times debugging starts to get slow.
>
> If you omit step 5, does the problem still happen?

Yes, the problem doesn't depend on recompiling. Its more to wait some
seconds before begin a new debugging cycle.

>
>> All debugging is done within the gud buffer using GDB commands.
>
> If, instead of stopping the process in step 4, you kill the gud 
> buffer
> through which you interact with GDB, do you still see the slowdown
> after several times that you kill and restart the debugging?

Killing the GUD buffer and starting a new debugging session totally
recovers to original performance.

Kalle

bug#11265: 24.0.94; gdb-mi very slow on Windows

[Eli Zaretskii]

> Date: Thu, 19 Apr 2012 08:10:09 +0200
> From: Karl-Heinz Schneider <karl-heinz@schneider-inet.de>
> Cc: <11265@debbugs.gnu.org>
> 
> >> I discovered that the slowdown happens after restarting the process 
> >> to
> >> debug.
> >> I did the following procedure:
> >>
> >> 1. Start the debugger (with process cmd-line).
> >> 2. Enter run to start the process
> >> 3. Debug the process
> >> 4. Enter kill to stop the process
> >> 5. Change code and recompile
> >> 6. Start again with step 2
> >>
> >> Doing this three or four times debugging starts to get slow.
> >
> > If you omit step 5, does the problem still happen?
> 
> Yes, the problem doesn't depend on recompiling. Its more to wait some
> seconds before begin a new debugging cycle.
> 
> >
> >> All debugging is done within the gud buffer using GDB commands.
> >
> > If, instead of stopping the process in step 4, you kill the gud 
> > buffer
> > through which you interact with GDB, do you still see the slowdown
> > after several times that you kill and restart the debugging?
> 
> Killing the GUD buffer and starting a new debugging session totally
> recovers to original performance.

If you can try the current development code on the emacs-24 branch,
please see if the problem is still there.  Some related problems were
fixed recently, and maybe they also fix your problem.  If you cannot
try the current code, please revisit this after the next pretest
version is released, and report back.  Thanks.

bug#11265: 24.0.94; gdb-mi very slow on Windows

[Karl-Heinz Schneider]

> If you can try the current development code on the emacs-24 branch,
> please see if the problem is still there.  Some related problems were
> fixed recently, and maybe they also fix your problem.  If you cannot
> try the current code, please revisit this after the next pretest
> version is released, and report back.  Thanks.

I just downloaded the zip-package 24.1.50 of emacs. The problem is
still there.

Kalle

bug#11265: 24.0.94; gdb-mi very slow on Windows

[Stefan Kangas]

Karl-Heinz Schneider <karl-heinz@schneider-inet.de> writes:

>> If you can try the current development code on the emacs-24 branch,
>> please see if the problem is still there.  Some related problems were
>> fixed recently, and maybe they also fix your problem.  If you cannot
>> try the current code, please revisit this after the next pretest
>> version is released, and report back.  Thanks.
>
> I just downloaded the zip-package 24.1.50 of emacs. The problem is
> still there.

This was 7 years ago.  Are you still seeing this on a modern version of
Emacs?

Best regards,
Stefan Kangas

bug#11265: 24.0.94; gdb-mi very slow on Windows

[Stefan Kangas]

Karl-Heinz Schneider <karl-heinz@schneider-inet.de> writes:

> >This was 7 years ago.  Are you still seeing this on a modern version of
> >Emacs?
>
> I think you can close this issue. I even don't use Emacs anymore for C++ coding these days. I even forgot about it, sorry.

Thanks for reporting back; closing the bug now.  If anyone else is
seeing this, please reopen the bug.

Best regards,
Stefan Kangas

bug#11265: 24.0.94; gdb-mi very slow on Windows

[Eli Zaretskii]

Forwarding this, for the record.

> Date: Wed, 18 Apr 2012 08:11:13 +0200
> From: Karl-Heinz Schneider <karl-heinz@schneider-inet.de>
> 
> Previously I used Emacs 23.3. This version didn't use GDB/MI as far as 
> I
> know. This worked very well most of the time.
> 
>  From the slowdown Emacs isn't affected completely. It's just working 
> with the
> debugger buffer. Change the focus from any other buffer to the GUD 
> buffer or
> typing in the GUD buffer is very slow. The slow down happens while 
> working with
> GUD. I prefer the keyboard, so I enter the GDB commands into the GUD 
> buffer.
> Any other not GUD related buffer works with usual speed.
> 
> I tried gud-gdb as well. Speed is good but it has other drawbacks. It 
> doesn't
> display the breakpoints within the source buffer and the gdb completion 
> doesn't
> work.
> 
> Kalle
>