gud slowness?

gud slowness?

[joakim]

I'm debugging Inkscape with gud, but its so slow as to be unusable.
Plain gdb debugging is not so slow.

Is this to be expected with trunk emacs or should I make a bug report?
-- 
Joakim Verona

Re: gud slowness?

[Miles Bader]

joakim@verona.se writes:
> I'm debugging Inkscape with gud, but its so slow as to be unusable.
> Plain gdb debugging is not so slow.
>
> Is this to be expected with trunk emacs or should I make a bug report?

I usually use "M-x gud-gdb" instead of "M-x gdb".

The former uses the old-style emacs gdb interface, and in general seems
to be much more usable and less buggy than the "new" emacs gdb code.

[This situation has been true basically as long as the new code has been
in emacs (~4 years?), and I've seen little indication that this is going
to change soon.]

-Miles

-- 
Scriptures, n. The sacred books of our holy religion, as distinguished from
the false and profane writings on which all other faiths are based.

Re: gud slowness?

[Stefan Monnier]

>> I'm debugging Inkscape with gud, but its so slow as to be unusable.
>> Plain gdb debugging is not so slow.
>> Is this to be expected with trunk emacs or should I make a bug report?

> I usually use "M-x gud-gdb" instead of "M-x gdb".

Same here.


        Stefan

Re: gud slowness?

[Eli Zaretskii]

> From: Miles Bader <miles@gnu.org>
> Date: Thu, 27 Jan 2011 11:30:35 +0900
> Cc: Emacs developers <emacs-devel@gnu.org>
> 
> I usually use "M-x gud-gdb" instead of "M-x gdb".
> 
> The former uses the old-style emacs gdb interface, and in general seems
> to be much more usable and less buggy than the "new" emacs gdb code.
> 
> [This situation has been true basically as long as the new code has been
> in emacs (~4 years?), and I've seen little indication that this is going
> to change soon.]

The old interface uses a GDB feature that's deprecated in GDB and can
disappear at any time.  So if there are serious problems with the
"new" gdb support code, we had better invest some effort into fixing
it.

Re: gud slowness?

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> The old interface uses a GDB feature that's deprecated in GDB and can
> disappear at any time.

For any in approximately never.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: gud slowness?

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: Miles Bader <miles@gnu.org>,  joakim@verona.se,  emacs-devel@gnu.org
> Date: Thu, 27 Jan 2011 10:14:21 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > The old interface uses a GDB feature that's deprecated in GDB and can
> > disappear at any time.
> 
> For any in approximately never.

If we are okay with this approximation, then IMO we should switch
"M-x gdb" back to use annotations.

Re: gud slowness?

[Eli Zaretskii]

> From: joakim@verona.se
> Date: Wed, 26 Jan 2011 21:36:08 +0100
> 
> I'm debugging Inkscape with gud, but its so slow as to be unusable.
> Plain gdb debugging is not so slow.

Can you give some numbers?

Re: gud slowness?

[joakim]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: joakim@verona.se
>> Date: Wed, 26 Jan 2011 21:36:08 +0100
>> 
>> I'm debugging Inkscape with gud, but its so slow as to be unusable.
>> Plain gdb debugging is not so slow.
>
> Can you give some numbers?

Ok. My machine is a fairly current core i7 laptop, Fedora x86_64 gnu/linux, 6gb
ram.

Plain gdb at a shell prompt and m-x gud-gdb are swift.

m-x gdb takes about a minute to initialize. Then I step a couple of
times through the debugger, and emacs eventually hangs. Not completely
as it still responds sluggishly to c-g. emacs continues to both slow
though.

It seems like Emacs is buzy-polling the subprocess but does it much too
quikly.

Incidently I have a similar issue with my own inkmacs.el bridge
to inkscape. Emacs is supposed to wait 10 seconds between polls, but
doesnt, so the loop is too fast, sinking the machine as a result.

-- 
Joakim Verona