all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* bug#11265: 24.0.94; gdb-mi very slow on Windows
@ 2012-04-17 14:21 Karl-Heinz Schneider
  2012-04-17 17:10 ` Eli Zaretskii
  0 siblings, 1 reply; 11+ messages in thread
From: Karl-Heinz Schneider @ 2012-04-17 14:21 UTC (permalink / raw)
  To: 11265

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.





^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#11265: 24.0.94; gdb-mi very slow on Windows
  2012-04-17 14:21 bug#11265: 24.0.94; gdb-mi very slow on Windows Karl-Heinz Schneider
@ 2012-04-17 17:10 ` Eli Zaretskii
  2012-04-18  1:56   ` Chong Yidong
                     ` (2 more replies)
  0 siblings, 3 replies; 11+ messages in thread
From: Eli Zaretskii @ 2012-04-17 17:10 UTC (permalink / raw)
  To: karl-heinz; +Cc: 11265

> 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.





^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#11265: 24.0.94; gdb-mi very slow on Windows
  2012-04-17 17:10 ` Eli Zaretskii
@ 2012-04-18  1:56   ` Chong Yidong
  2012-04-18 17:00     ` Eli Zaretskii
       [not found]   ` <4a9b5bb0b0553d31ee6df5994fd8a56d@schneider-inet.de>
       [not found]   ` <669ef4eefd097d3da673c9f368045ea2@schneider-inet.de>
  2 siblings, 1 reply; 11+ messages in thread
From: Chong Yidong @ 2012-04-18  1:56 UTC (permalink / raw)
  To: karl-heinz; +Cc: 11265

> 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.





^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#11265: 24.0.94; gdb-mi very slow on Windows
       [not found]   ` <4a9b5bb0b0553d31ee6df5994fd8a56d@schneider-inet.de>
@ 2012-04-18 16:30     ` Eli Zaretskii
  2012-04-19  6:10       ` Karl-Heinz Schneider
  0 siblings, 1 reply; 11+ messages in thread
From: Eli Zaretskii @ 2012-04-18 16:30 UTC (permalink / raw)
  To: karl-heinz; +Cc: 11265

[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?





^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#11265: 24.0.94; gdb-mi very slow on Windows
       [not found]   ` <669ef4eefd097d3da673c9f368045ea2@schneider-inet.de>
@ 2012-04-18 16:31     ` Eli Zaretskii
  0 siblings, 0 replies; 11+ messages in thread
From: Eli Zaretskii @ 2012-04-18 16:31 UTC (permalink / raw)
  To: 11265

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
> 





^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#11265: 24.0.94; gdb-mi very slow on Windows
  2012-04-18  1:56   ` Chong Yidong
@ 2012-04-18 17:00     ` Eli Zaretskii
  0 siblings, 0 replies; 11+ messages in thread
From: Eli Zaretskii @ 2012-04-18 17:00 UTC (permalink / raw)
  To: Chong Yidong; +Cc: karl-heinz, 11265

> 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.





^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#11265: 24.0.94; gdb-mi very slow on Windows
  2012-04-18 16:30     ` Eli Zaretskii
@ 2012-04-19  6:10       ` Karl-Heinz Schneider
  2012-04-20  7:49         ` Eli Zaretskii
  0 siblings, 1 reply; 11+ messages in thread
From: Karl-Heinz Schneider @ 2012-04-19  6:10 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 11265

>> 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





^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#11265: 24.0.94; gdb-mi very slow on Windows
  2012-04-19  6:10       ` Karl-Heinz Schneider
@ 2012-04-20  7:49         ` Eli Zaretskii
  2012-04-24 14:57           ` Karl-Heinz Schneider
  0 siblings, 1 reply; 11+ messages in thread
From: Eli Zaretskii @ 2012-04-20  7:49 UTC (permalink / raw)
  To: karl-heinz; +Cc: 11265

> 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.





^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#11265: 24.0.94; gdb-mi very slow on Windows
  2012-04-20  7:49         ` Eli Zaretskii
@ 2012-04-24 14:57           ` Karl-Heinz Schneider
  2019-11-01 19:51             ` Stefan Kangas
  0 siblings, 1 reply; 11+ messages in thread
From: Karl-Heinz Schneider @ 2012-04-24 14:57 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 11265

> 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





^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#11265: 24.0.94; gdb-mi very slow on Windows
  2012-04-24 14:57           ` Karl-Heinz Schneider
@ 2019-11-01 19:51             ` Stefan Kangas
       [not found]               ` <21C01CB2-EBC0-47D7-8F57-D5801A15C5FD@schneider-inet.de>
  0 siblings, 1 reply; 11+ messages in thread
From: Stefan Kangas @ 2019-11-01 19:51 UTC (permalink / raw)
  To: Karl-Heinz Schneider; +Cc: 11265

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





^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#11265: 24.0.94; gdb-mi very slow on Windows
       [not found]               ` <21C01CB2-EBC0-47D7-8F57-D5801A15C5FD@schneider-inet.de>
@ 2019-11-05 13:46                 ` Stefan Kangas
  0 siblings, 0 replies; 11+ messages in thread
From: Stefan Kangas @ 2019-11-05 13:46 UTC (permalink / raw)
  To: Karl-Heinz Schneider, 11265-done

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





^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2019-11-05 13:46 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-04-17 14:21 bug#11265: 24.0.94; gdb-mi very slow on Windows Karl-Heinz Schneider
2012-04-17 17:10 ` Eli Zaretskii
2012-04-18  1:56   ` Chong Yidong
2012-04-18 17:00     ` Eli Zaretskii
     [not found]   ` <4a9b5bb0b0553d31ee6df5994fd8a56d@schneider-inet.de>
2012-04-18 16:30     ` Eli Zaretskii
2012-04-19  6:10       ` Karl-Heinz Schneider
2012-04-20  7:49         ` Eli Zaretskii
2012-04-24 14:57           ` Karl-Heinz Schneider
2019-11-01 19:51             ` Stefan Kangas
     [not found]               ` <21C01CB2-EBC0-47D7-8F57-D5801A15C5FD@schneider-inet.de>
2019-11-05 13:46                 ` Stefan Kangas
     [not found]   ` <669ef4eefd097d3da673c9f368045ea2@schneider-inet.de>
2012-04-18 16:31     ` Eli Zaretskii

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.