debugging mozilla with gdb is so slow

debugging mozilla with gdb is so slow

[Brian Stell]

I find that using gdb to debug Mozilla very slow.

It is so slow that I find many (most?) Linux Mozilla 
developers use printfs because they "need to get work done".

My startup time (time to the first moz window) is really 
long when I use gdb:

  Mozilla no gdb:   11 sec
  Mozilla with gdb: 125 sec

This does not seem to meet the goal in the gdb docs:

    GDB should be responsive to the user.  A programmer 
    hot on the trail of a nasty bug, and operating under 
    a looming deadline, is going to be very impatient of 
    everything, including the response time to debugger
    commands.

( http://www.math.psu.edu/doc/emacs/info/gdbint.info-1 )

Gdb itself comes up fairly fast ~ 5-10 sec. This long
start delay makes it basically unusable.

I have a 500MHz P3 Linux Redhat 6.2 system with 512M ram.

Any thoughts?

Brian Stell

Re: debugging mozilla with gdb is so slow

[Daniel Berlin]

bstell@netscape.com (Brian Stell) writes:

> I find that using gdb to debug Mozilla very slow.
> 
> It is so slow that I find many (most?) Linux Mozilla 
> developers use printfs because they "need to get work done".
> 
> My startup time (time to the first moz window) is really 
> long when I use gdb:
> 
>   Mozilla no gdb:   11 sec
>   Mozilla with gdb: 125 sec
> 
> This does not seem to meet the goal in the gdb docs:
> 
>     GDB should be responsive to the user.  A programmer 
>     hot on the trail of a nasty bug, and operating under 
>     a looming deadline, is going to be very impatient of 
>     everything, including the response time to debugger
>     commands.
> 
> ( http://www.math.psu.edu/doc/emacs/info/gdbint.info-1 )
> 
> Gdb itself comes up fairly fast ~ 5-10 sec. This long
> start delay makes it basically unusable.
> 
> I have a 500MHz P3 Linux Redhat 6.2 system with 512M ram.
> 
> Any thoughts?

Yes.

I have patches that can drastically reduce this time.

I haven't touched them in months.

They include:

1.mmaping the debug info when mmap is available (through bfd file
windows), rather than allocating huge blocks of memory, and reading
the entire section into it, like we do now.

2.Using a ternary search trie to do demangled name lookups before
redemangling (to save time and memory), and replacing the minsym hash
tables with a ternary search trie, since a  hash table is the wrong
structure for this, and performs *amazingly* badly at it (because
unsuccessful lookups, require as much time as successful ones, the
hash table number of buckets is *way* too small, the hashing algorithm
is bad (O(n), for starters), etc).

And a bunch of other stuff from profiling debugging programs with >
100 meg of debug info.

I'll be submitting the patch to do number 2 after i finish the new C++
abi support. The patch for number 1, you need to convince the bfd guys
to turn on the file window stuff even when mmap isn't available, and
just make it do it the stupid way. That way, we can just replace what
we do now with the file window stuff, and not have to special case it.


Are you swapping heavily, too, when trying to run it under GDB?
If not, you are just getting hit with various "too slow"
algorithms. If you are, you are also getting him with symbol
duplication, and using way more memory than we need to, in a lot of
cases (usually by a factor of 5 or 10).
--Dan


> 
> Brian Stell

Re: debugging mozilla with gdb is so slow

[Brian Stell]

Daniel Berlin wrote:
> 
> bstell@netscape.com (Brian Stell) writes:
> > I find that using gdb to debug Mozilla very slow.
> > ...
> 
> I have patches that can drastically reduce this time.
> ...
> Are you swapping heavily, too, when trying to run it under GDB?

No, the disk light is not on at all (a benefit of 512Meg ram).

Brian Stell