* Re: Improving GDB startup time with large programs
@ 2004-05-02 22:49 Michael Elizabeth Chastain
2004-05-02 23:11 ` Nick Savoiu
2004-05-03 2:49 ` Nick Savoiu
0 siblings, 2 replies; 9+ messages in thread
From: Michael Elizabeth Chastain @ 2004-05-02 22:49 UTC (permalink / raw)
To: gdb, savoiu
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Improving GDB startup time with large programs
2004-05-02 22:49 Improving GDB startup time with large programs Michael Elizabeth Chastain
@ 2004-05-02 23:11 ` Nick Savoiu
2004-05-03 2:49 ` Nick Savoiu
1 sibling, 0 replies; 9+ messages in thread
From: Nick Savoiu @ 2004-05-02 23:11 UTC (permalink / raw)
To: gdb
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Improving GDB startup time with large programs
2004-05-02 22:49 Improving GDB startup time with large programs Michael Elizabeth Chastain
2004-05-02 23:11 ` Nick Savoiu
@ 2004-05-03 2:49 ` Nick Savoiu
2004-05-03 17:17 ` Nick Savoiu
2004-05-04 19:44 ` Daniel Jacobowitz
1 sibling, 2 replies; 9+ messages in thread
From: Nick Savoiu @ 2004-05-03 2:49 UTC (permalink / raw)
To: gdb
>> 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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Improving GDB startup time with large programs
2004-05-03 2:49 ` Nick Savoiu
@ 2004-05-03 17:17 ` Nick Savoiu
2004-05-04 19:44 ` Daniel Jacobowitz
1 sibling, 0 replies; 9+ messages in thread
From: Nick Savoiu @ 2004-05-03 17:17 UTC (permalink / raw)
To: gdb
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Improving GDB startup time with large programs
2004-05-03 2:49 ` Nick Savoiu
2004-05-03 17:17 ` Nick Savoiu
@ 2004-05-04 19:44 ` Daniel Jacobowitz
1 sibling, 0 replies; 9+ messages in thread
From: Daniel Jacobowitz @ 2004-05-04 19:44 UTC (permalink / raw)
To: Nick Savoiu; +Cc: gdb
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Improving GDB startup time with large programs
2004-05-03 1:56 Michael Elizabeth Chastain
@ 2004-05-03 15:00 ` Andrew Cagney
0 siblings, 0 replies; 9+ messages in thread
From: Andrew Cagney @ 2004-05-03 15:00 UTC (permalink / raw)
To: Michael Elizabeth Chastain, savoiu; +Cc: gdb
>>> 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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Improving GDB startup time with large programs
@ 2004-05-03 3:39 Michael Elizabeth Chastain
0 siblings, 0 replies; 9+ messages in thread
From: Michael Elizabeth Chastain @ 2004-05-03 3:39 UTC (permalink / raw)
To: gdb, savoiu
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Improving GDB startup time with large programs
@ 2004-05-03 1:56 Michael Elizabeth Chastain
2004-05-03 15:00 ` Andrew Cagney
0 siblings, 1 reply; 9+ messages in thread
From: Michael Elizabeth Chastain @ 2004-05-03 1:56 UTC (permalink / raw)
To: gdb, savoiu
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Improving GDB startup time with large programs
@ 2004-05-02 22:12 Nick Savoiu
0 siblings, 0 replies; 9+ messages in thread
From: Nick Savoiu @ 2004-05-02 22:12 UTC (permalink / raw)
To: gdb
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
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2004-05-04 19:44 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-05-02 22:49 Improving GDB startup time with large programs Michael Elizabeth Chastain
2004-05-02 23:11 ` Nick Savoiu
2004-05-03 2:49 ` Nick Savoiu
2004-05-03 17:17 ` Nick Savoiu
2004-05-04 19:44 ` Daniel Jacobowitz
-- strict thread matches above, loose matches on Subject: below --
2004-05-03 3:39 Michael Elizabeth Chastain
2004-05-03 1:56 Michael Elizabeth Chastain
2004-05-03 15:00 ` Andrew Cagney
2004-05-02 22:12 Nick Savoiu
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).