emacs-pretest-bug
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

M-x gdb with large files [was Re: gud-tooltip-mode:...]


From: Nick Roberts
Subject: M-x gdb with large files [was Re: gud-tooltip-mode:...]
Date: Sun, 28 May 2006 12:20:49 +1200

 > I also have serious performance issues with the new gdb interface, e.g.
 >  gdb --fullname <image-name> core
 > and then "up" or "bt" in gdb takes a bit more than 20 seconds, whereas
 >  gdba -annotate=3 <image-name> core
 > and then "up" or "bt" needs 2 and a half minutes.
 > This is almost certainly not an emacs problem, but seems to be caused by
 > the --annotate=3 option for gdb and of course our image size (125 MB and
 > 155 for the core file).

I have thought a bit more about this.

Assuming its not just a memory problem (GDB in Emacs will need more memory
than GDB on its own):

Did you do this with gdb-many-windows set to t?

Is typing "up" this slow when the stack-buffer ("*stack frames of ...") isn't
present?  This is the case if you start with the nil for gdb-many-windows (the
default value).  By default, I try to get Emacs to use as little as possible,
then its up to the user what he requests.  If speed/resources are a problem,
you can invoke further buffers separately through the menu bar, rather than
with gdb-many-windows (3 or 4 extra buffers).

How deep is your stack?  

If it is the display of the stack-buffer that's slowing things up, perhaps at
some point, when you have some free time, you can try restricting the
stack.  Assuming it's much deeper than 50, in gdb-ui.el could you replace:

(def-gdb-auto-updated-buffer gdb-stack-buffer
  gdb-invalidate-frames
  "server info stack\n"
  gdb-info-stack-handler
  gdb-info-stack-custom)

with something like:

(def-gdb-auto-updated-buffer gdb-stack-buffer
  gdb-invalidate-frames
  "server info stack 50\n"
  gdb-info-stack-handler
  gdb-info-stack-custom)

Would that be useful as a customisable option?

I think GDB caches the stack, so "bt" should only take a long time if it
thinks the stack has changed, which presumably can't happen with a core file.
Emacs could still take a long time to compute the buffer, I guess, if there
are thousands of frames.

Does anyone on the list know what commercial debuggers like Visual Studio or
Totalview do about displaying the stack when the debugged program has
thousands of frames?

-- 
Nick                                           http://www.inet.net.nz/~nickrob




reply via email to

[Prev in Thread] Current Thread [Next in Thread]