GDB startup

GDB startup

[Stefan Monnier]

I see a significant delay when I start M-x gdb, where the *gdb*
buffer is shown with most of the gdb's startup output displayed, except for
the prompt.  After about 10s, the prompt finally shows up.

I suspect it's due to the new feature "go through all buffers and ask the
gdb subprocess whether it should be put in gud-gdb-minor-mode".  I have many
buffers open, so I guess this loop takes a while.

Would it be possible to "do it in the background", maybe?


        Stefan

GDB startup

[Nick Roberts]

 > I see a significant delay when I start M-x gdb, where the *gdb*
 > buffer is shown with most of the gdb's startup output displayed, except for
 > the prompt.  After about 10s, the prompt finally shows up.
 > 
 > I suspect it's due to the new feature "go through all buffers and ask the
 > gdb subprocess whether it should be put in gud-gdb-minor-mode".  I have many
 > buffers open, so I guess this loop takes a while.
 > 
 > Would it be possible to "do it in the background", maybe?

I'm not sure what you mean. GDB runs asynchronously from Emacs, so all
commands sent to it *do* run in the background. Maybe, because there is so
much input and output, you can't get the prompt so it feels like its running
in foreground.

Presumably a lot of your buffers aren't visible which makes me wonder whether
its possible to have a when-buffer-becomes-visible-hook?

A more practical solution might be to limit the number of buffers/files (its
probably the latter which takes most time) that Emacs considers. Clearly, what
is a sensible number would depend on the speed of the computer (I think that
perhaps you have a clunky machine). Generally, how many buffers do you have
open with files in them?


Nick

Re: GDB startup

[Stefan Monnier]

>> Would it be possible to "do it in the background", maybe?

> I'm not sure what you mean.  GDB runs asynchronously from Emacs, so all
> commands sent to it *do* run in the background.  Maybe, because there is
> so much input and output, you can't get the prompt so it feels like its
> running in foreground.

I understand that it's not clear what I mean by "in the background" (that's
why I put it between quotes): I understand that those commands are sent
asynchronously and so Emacs is not stuck waiting, but gdb is kept
sufficiently busy that the prompt doesn't appear.

> Presumably a lot of your buffers aren't visible

Indeed the large majority of my buffers are in iconified frames.

> which makes me wonder whether its possible to have
> a when-buffer-becomes-visible-hook?

I guess post-command-hook is the closest thing.

Maybe another approach is to limit the buffers that are considered to some
set of major modes, or to some subtree of the filesystem.  But neither seems
quite practical.

Another alternative could be to handle the files/buffers "slowly", with
a 0.5s delay between each file/buffer, starting with the buffers that are
currently visible.

> A more practical solution might be to limit the number of buffers/files
> (its probably the latter which takes most time) that Emacs considers.
> Clearly, what is a sensible number would depend on the speed of the
> computer (I think that perhaps you have a clunky machine).

2GB, 1.4GHz Opteron.  It's not the bestest and greatest, but it hardly
qualifies as clunky.

> Generally, how many buffers do you have open with files in them?

Anywhere between 20 and 100.  Let's say in the 50s.


        Stefan

Re: GDB startup

[Nick Roberts]

 > Maybe another approach is to limit the buffers that are considered to some
 > set of major modes, or to some subtree of the filesystem.  But neither seems
 > quite practical.
 >
 > Another alternative could be to handle the files/buffers "slowly", with
 > a 0.5s delay between each file/buffer, starting with the buffers that are
 > currently visible.

I'm not sure that I like either of these very much but here are other
alternatives. Currently gdb-ui.el uses the GDB command "info source" to find
out if a file is part of the source code of the debug session.  There is
another command, "info sources", that lists all the files that are part of the
source code. Unfortunately only recent versions of GDB give the full pathname
for these files, and as it is CLI output the exact syntax might not always be
consistent. However, there is also an MI command,
-file-list-exec-source-files, that provides this information in a way that can
be parsed more simply. This command was added in GDB 6.2, I think.

I have also modified MI commands so that, in Emacs, the locals buffer and
watch expressions in the speedbar display better information more quickly.
These changes were added in version 6.1. GDB get released about two times a
year and the current version is 6.3.

There is a choice to be made before the next release of Emacs:

1) We can use these new features to improve the behaviour/performance of Emacs
   with GDB and accept that it won't work with older versions of GDB.

or

2) We can accept the current behaviour/performance so that it works with older
   versions of GDB.

As time goes by, 1) becomes more attractive but because there has been no
timeline for its release since the "feature freeze" ten months ago (it might
be next week or it might be next year) I have conservatively followed 2).


Nick

Re: GDB startup

[Miles Bader]

On Tue, 15 Feb 2005 20:16:02 -0500, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
> I guess post-command-hook is the closest thing.

It gets used way too much though -- we shouldn't be sticking all kinds
of random crap on post-command-hook...

-Miles
-- 
Do not taunt Happy Fun Ball.

Re: GDB startup

[Kim F. Storm]

Miles Bader <snogglethorpe@gmail.com> writes:

> On Tue, 15 Feb 2005 20:16:02 -0500, Stefan Monnier
> <monnier@iro.umontreal.ca> wrote:
>> I guess post-command-hook is the closest thing.
>
> It gets used way too much though -- we shouldn't be sticking all kinds
> of random crap on post-command-hook...

I agree.

But post-command-idle-hook might be useful in some way...

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: GDB startup

[Luc Teirlinck]

Kim Storm wrote:

   I agree.

   But post-command-idle-hook might be useful in some way...

>From the docstring:

    post-command-idle-hook's value is nil

    This variable is obsolete since before 19.34;
    use timers instead, with `run-with-idle-timer'.

So, if one wants to use it, one should probably resurrect it from
a long obsolescence.

Sincerely,

Luc.

Re: GDB startup

[Kim F. Storm]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

>     post-command-idle-hook's value is nil
>
>     This variable is obsolete since before 19.34;

Ouch.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk