Re: Improving GDB startup time with large programs

Re: Improving GDB startup time with large programs

[Michael Elizabeth Chastain]

Which version of gdb are you using?
What platform are you running on?
Is it native or cross?  If it's cross, what is the target platform?
What language is your program written in?
What compiler and debug options are you using on your program?

The answer is probably 'file a PR with lots of information about what
you are doing, and then do some profiling on gdb to help us out, and
then maybe the next release of gdb will be faster'.

If you are running gdb 6.0 or earlier, and if your program is written in
C++, then gdb 6.1 will load faster because of its new C++ demangler.
That's the major speed improvement lately that I'm aware of.  Daniel J
knows a lot more about other speed improvements than I do.

Michael C
GDB QA Guy

Re: Improving GDB startup time with large programs

[Nick Savoiu]

Hi Michael,

Thanks for the quick reply.

> Which version of gdb are you using?

I'm currently using 6.1 to which I have just upgraded. However, it seems about 
15% slower at startup than 6.0 despite my expectations that it would be 
faster.

> What platform are you running on?

I'm running on RedHat 8.0.

> Is it native or cross?  If it's cross, what is the target platform?

It's a native debugger.

> What language is your program written in?

95% C++

> What compiler and debug options are you using on your program?

I'm using g++ 3.2 with '-Wall -Wno-unused -g'

> The answer is probably 'file a PR with lots of information about what
> you are doing, and then do some profiling on gdb to help us out, and
> then maybe the next release of gdb will be faster'.

How do I profile gdb?

Nick

Re: Improving GDB startup time with large programs

[Nick Savoiu]

>> How do I profile gdb?
>
>When you build gdb, configure as normal.
>Then use this command to build:

Here's what I got (the most significant stuff) with g++ 3.2. Seems that the number of symbols is the culprit.

Nick

--------------------------------

Flat profile:

Each sample counts as 0.01 seconds.
  %   cumulative   self              self     total           
 time   seconds   seconds    calls   s/call   s/call  name    
 18.61      1.93     1.93  2013562     0.00     0.00  hash
 13.55      3.33     1.41  9757458     0.00     0.00  strcmp_iw_ordered
 11.86      4.57     1.23  2310964     0.00     0.00  htab_hash_string
  9.55      5.55     0.99  6206314     0.00     0.00  read_partial_die
  4.97      6.07     0.52  1906172     0.00     0.00  bcache_data
  3.38      6.42     0.35  5101168     0.00     0.00  read_indirect_string
  3.33      6.76     0.34 23770551     0.00     0.00  read_attribute_value
  3.18      7.09     0.33   948693     0.00     0.00  d_print_comp
  2.60      7.37     0.27  2032858     0.00     0.00  htab_find_slot_with_hash
  1.59      7.53     0.17  9203512     0.00     0.00  read_unsigned_leb128
  1.54      7.69     0.16 23770551     0.00     0.00  read_attribute
  1.25      7.82     0.13   256652     0.00     0.00  find_last_component
  1.25      7.95     0.13   131142     0.00     0.00  msymbol_hash_iw
  1.16      8.07     0.12  6643402     0.00     0.00  dwarf2_lookup_abbrev
  1.16      8.19     0.12  3934670     0.00     0.00  d_make_comp
  1.06      8.30     0.11  1906172     0.00     0.00  add_psymbol_to_list
  0.96      8.40     0.10    89224     0.00     0.00  cp_find_first_component_aux
  0.87      8.49     0.09 19615690     0.00     0.00  symbol_natural_name
  0.87      8.58     0.09 12864595     0.00     0.00  bfd_getl32
  0.87      8.67     0.09     1699     0.00     0.00  scan_partial_symbols
  0.77      8.75     0.08  2032858     0.00     0.00  symbol_set_names
  0.68      8.82     0.07 11166899     0.00     0.00  read_1_byte

Re: Improving GDB startup time with large programs

[Nick Savoiu]

For comparison here are the GDB 6.0 results:

Flat profile:

Each sample counts as 0.01 seconds.
  %   cumulative   self              self     total           
 time   seconds   seconds    calls   s/call   s/call  name    
 32.24      2.36     2.36  2013564     0.00     0.00  hash
 16.12      3.54     1.18  2300832     0.00     0.00  htab_hash_string
  6.42      4.01     0.47  3975016     0.00     0.00  read_partial_die
  5.46      4.41     0.40  1906174     0.00     0.00  bcache
  3.21      4.64     0.23  2024256     0.00     0.00  htab_find_slot_with_hash
  2.60      4.83     0.19   591490     0.00     0.00  dyn_string_substring
  2.32      5.00     0.17   436495     0.00     0.00  strcmp_iw_ordered
  1.98      5.15     0.14 11899013     0.00     0.00  read_attribute_value
  1.78      5.28     0.13   118643     0.00     0.00  msymbol_hash
  1.57      5.39     0.12  6972300     0.00     0.00  read_unsigned_leb128
  1.50      5.50     0.11  4412114     0.00     0.00  dwarf2_lookup_abbrev
  1.50      5.62     0.11  2128935     0.00     0.00  read_indirect_string
  1.30      5.71     0.10  1906174     0.00     0.00  add_psymbol_to_list
  1.23      5.80     0.09    74808     0.00     0.00  msymbol_hash_iw
  1.16      5.88     0.09  6507274     0.00     0.00  dyn_string_resize
  1.09      5.96     0.08 11899013     0.00     0.00  read_attribute
  1.02      6.04     0.07     1699     0.00     0.00  scan_partial_symbols

Nick

On Sunday 02 May 2004 07:48 pm, Nick Savoiu wrote:
> >> How do I profile gdb?
> >
> >When you build gdb, configure as normal.
> >Then use this command to build:
>
> Here's what I got (the most significant stuff) with g++ 3.2. Seems that the
> number of symbols is the culprit.
>
> Nick
>
> --------------------------------
>
> Flat profile:
>
> Each sample counts as 0.01 seconds.
>   %   cumulative   self              self     total
>  time   seconds   seconds    calls   s/call   s/call  name
>  18.61      1.93     1.93  2013562     0.00     0.00  hash
>  13.55      3.33     1.41  9757458     0.00     0.00  strcmp_iw_ordered
>  11.86      4.57     1.23  2310964     0.00     0.00  htab_hash_string
>   9.55      5.55     0.99  6206314     0.00     0.00  read_partial_die
>   4.97      6.07     0.52  1906172     0.00     0.00  bcache_data
>   3.38      6.42     0.35  5101168     0.00     0.00  read_indirect_string
>   3.33      6.76     0.34 23770551     0.00     0.00  read_attribute_value
>   3.18      7.09     0.33   948693     0.00     0.00  d_print_comp
>   2.60      7.37     0.27  2032858     0.00     0.00 
> htab_find_slot_with_hash 1.59      7.53     0.17  9203512     0.00     0.00
>  read_unsigned_leb128 1.54      7.69     0.16 23770551     0.00     0.00 
> read_attribute 1.25      7.82     0.13   256652     0.00     0.00 
> find_last_component 1.25      7.95     0.13   131142     0.00     0.00 
> msymbol_hash_iw 1.16      8.07     0.12  6643402     0.00     0.00 
> dwarf2_lookup_abbrev 1.16      8.19     0.12  3934670     0.00     0.00 
> d_make_comp
>   1.06      8.30     0.11  1906172     0.00     0.00  add_psymbol_to_list
>   0.96      8.40     0.10    89224     0.00     0.00 
> cp_find_first_component_aux 0.87      8.49     0.09 19615690     0.00    
> 0.00  symbol_natural_name 0.87      8.58     0.09 12864595     0.00    
> 0.00  bfd_getl32
>   0.87      8.67     0.09     1699     0.00     0.00  scan_partial_symbols
>   0.77      8.75     0.08  2032858     0.00     0.00  symbol_set_names
>   0.68      8.82     0.07 11166899     0.00     0.00  read_1_byte

Re: Improving GDB startup time with large programs

[Daniel Jacobowitz]

On Sun, May 02, 2004 at 07:48:50PM -0700, Nick Savoiu wrote:
> >> How do I profile gdb?
> >
> >When you build gdb, configure as normal.
> >Then use this command to build:
> 
> Here's what I got (the most significant stuff) with g++ 3.2. Seems
> that the number of symbols is the culprit.

First of all, as Andrew said, use something like oprofile instead of
gprof / -pg profiling.  The top three functions on your profile below
are called extremely often and do extremely little work -> call graph
profiling inflates their time significantly.

Secondly, the big change in the 6.0 / 6.1 profiles you've posted is the
increased use of strcmp_iw_ordered.  David Carlton noticed that this
change was in fact necessary for correctness.  I've been thinking about
alternate approaches to avoid it - the comparison is quite expensive -
but it's going to take a lot of work.

Third, most of the time in your example is spent reading partial
symbols.  If you use a GCC new enough to support
-g -feliminate-dwarf2-dups, and a GDB snapshot from the
"drow_intercu-20040221-branch" branch of CVS, there will be many fewer
partial symbols; that should improve your startup time somewhat.

-- 
Daniel Jacobowitz

Re: Improving GDB startup time with large programs

[Andrew Cagney]

>>> How do I profile gdb?
> 
> 
> When you build gdb, configure as normal.
> Then use this command to build:
> 
>   make CFLAGS='-pg'

Using oprofile is more useful that gprof - it's system wide and less 
intrusive.

Andrew

Re: Improving GDB startup time with large programs

[Michael Elizabeth Chastain]

Yeah.  Nothing egregiously bad leaps out at me from this information.

You could try compiling big parts of your program with "-g1"
instead of "-g".  The default "-g" level is "-g2", which produces
much more debug info.

Also, in the future, maybe the linker could remove duplicate
information from dwarf-2 sections.

Michael C

Re: Improving GDB startup time with large programs

[Michael Elizabeth Chastain]

Hi Nick,

> I'm currently using 6.1 to which I have just upgraded. However, it seems
> about 15% slower at startup than 6.0 despite my expectations that it
> would be faster.

That's a bummer.  I have one large C++ program, the 'monotone'
executable, that got a lot faster (native i686-pc-linux-gnu,
red hat 8.0, gcc 3.3.something).

> I'm using g++ 3.2 with '-Wall -Wno-unused -g'

You could try upgrading to g++ 3.3.3 or g++ 3.4.0.
Basically, if you have a lot of disk space, and you configure
the compiler with '--prefix=...', you can play with different
compilers.

I have no reason to think that will actually help any, though.

> How do I profile gdb?

When you build gdb, configure as normal.
Then use this command to build:

  make CFLAGS='-pg'

Then install as normal.

(As you might already know, experimenting with different versions of gdb
is a lot easier and safer if you use --prefix=... when configuring it.
I have dozens of gcc's and several gdb's on my system at any time).

Then run the new gdb as you normally would on your test program.
Make sure to quit gdb cleanly at the end.

Look for a file named 'gmon.out'.  This is the data file from the
profiler.  Then run 'gprof /path/to/installed/bin/gdb' to see the
output.  It will have this kind of format:

  Flat profile:

  Each sample counts as 0.01 seconds.
    %   cumulative   self              self     total
   time   seconds   seconds    calls  ms/call  ms/call  name
   16.67      0.01     0.01   175396     0.00     0.00  symbol_natural_name
   16.67      0.02     0.01    27446     0.00     0.00  htab_find_slot_with_hash
   16.67      0.03     0.01    15575     0.00     0.00  read_partial_die
   16.67      0.04     0.01      146     0.07     0.10  dwarf2_read_abbrevs
   16.67      0.05     0.01        7     1.43     1.98  find_methods
    8.33      0.06     0.01     6466     0.00     0.00  xrealloc
    8.33      0.06     0.01       31     0.16     0.16  xcalloc

  ...

Now, if you can do this for gdb 6.0 versus gdb 6.1, and report the
top 15-20 lines of the profile output, that would be interesting data.
And then there's the CVS version of gdb.

Michael C

Improving GDB startup time with large programs

[Nick Savoiu]

Hi,

I have a rather large project for which I would like to improve the debugging 
startup time. Right now it takes GDB a good 20-30 seconds (loading symbols 
and such, I assume) from invoking 'run' to really executing the debugged 
program.

Does anyone have info or a pointer to info on how to optimize this?

Thanks,
Nick