* Huge slowdown since 6.0
@ 2004-02-18 21:09 Daniel Jacobowitz
2004-02-18 21:31 ` David Carlton
2004-02-19 1:59 ` Elena Zannoni
0 siblings, 2 replies; 29+ messages in thread
From: Daniel Jacobowitz @ 2004-02-18 21:09 UTC (permalink / raw)
To: carlton, gdb
I finished prototyping my partial-symbol-sorting changes, as discussed on
gdb-patches, and went to measure their impact. The results were a little
confusing, but I've tracked them down. At the bottom of my message are
profiling numbers if you want to see them. The summary is that I hope they
won't be needed.
Basically, the bottleneck in strcmp_iw_ordered that I am attacking was not
there in 6.0. This baffled me. There were just as many psymbols and there
should have been just as many calls; the change to use strcmp_iw_ordered
predates 6.0.
The only reasonable explanation is that the number of global symbols has
vastly increased. This appears to be the case. David, the blame appears to
be yours, in dwarf2read.c revision 1.120:
@@ -1519,14 +1556,16 @@ add_partial_symbol (struct partial_die_i
/* For C++, these implicitly act as typedefs as well. */
add_psymbol_to_list (actual_name, strlen (actual_name),
VAR_DOMAIN, LOC_TYPEDEF,
- &objfile->static_psymbols,
+ &objfile->global_psymbols,
0, (CORE_ADDR) 0, cu_language, objfile);
}
break;
case DW_TAG_enumerator:
add_psymbol_to_list (actual_name, strlen (actual_name),
VAR_DOMAIN, LOC_CONST,
- &objfile->static_psymbols,
+ cu_language == language_cplus
+ ? &objfile->static_psymbols
+ : &objfile->global_psymbols,
0, (CORE_ADDR) 0, cu_language, objfile);
break;
default:
Could you re-explain the need for this change, please? You said:
+ /* NOTE: carlton/2003-11-10: C++ class symbols shouldn't
+ really ever be static objects: otherwise, if you try
+ to, say, break of a class's method and you're in a file
+ which doesn't mention that class, it won't work unless
+ the check for all static symbols in lookup_symbol_aux
+ saves you. See the OtherFileClass tests in
+ gdb.c++/namespace.exp. */
+
but is that also necessary for enumerators? As things stand, one large enum
in a used header can lead to worse-than-linear slowdown of GDB startup for
DWARF-2, and a couple megabytes of wasted memory.
Profiling information:
HEAD:
% time /opt/src/gdb/x86-as/gdb/gdb -batch /usr/lib/debug/libc.so.6
Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
/opt/src/gdb/x86-as/gdb/gdb -batch /usr/lib/debug/libc.so.6 3.35s user 0.32s system 97% cpu 3.751 total
With my changes:
drow@nevyn:/big/fsf/projects/sym-full-name/ot% time ../obj/gdb/gdb -batch /usr/lib/debug/libc.so.6
Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
../obj/gdb/gdb -batch /usr/lib/debug/libc.so.6 2.43s user 0.21s system 99% cpu 2.656 total
Awesome! 28% speedup. But:
6.0:
% time ./gdb/gdb -batch /usr/lib/debug/libc.so.6
./gdb/gdb -batch /usr/lib/debug/libc.so.6 1.95s user 0.26s system 96% cpu 2.288 total
So it recovers a bare half of what we've lost since GDB 6.0. All binaries
built using the same compiler and CFLAGS (-O2).
Profiles for 6.0:
% cumulative self self total
time samples samples calls T1/call T1/call name
28.46 9128.00 9128.00 bcache
10.92 12631.00 3503.00 read_partial_die
9.10 15549.00 2918.00 hash
8.13 18155.00 2606.00 htab_find_slot_with_hash
5.57 19943.00 1788.00 read_attribute_value
5.11 21581.00 1638.00 htab_hash_string
3.80 22799.00 1218.00 read_unsigned_leb128
...
0.04 31769.00 14.00 strcmp_iw_ordered
...
0.01 32011.00 2.00 compare_psymbols
For HEAD:
% cumulative self self total
time samples samples calls T1/call T1/call name
19.00 8696.00 8696.00 strcmp_iw_ordered
16.31 16162.00 7466.00 bcache_data
7.50 19594.00 3432.00 read_partial_die
6.63 22630.00 3036.00 htab_find_slot_with_hash
4.93 24888.00 2258.00 hash
4.87 27118.00 2230.00 symbol_natural_name
3.94 28923.00 1805.00 read_attribute_value
3.69 30611.00 1688.00 htab_hash_string
3.28 32111.00 1500.00 _init
2.95 33461.00 1350.00 compare_psymbols
With my changes:
% cumulative self self total
time samples samples calls T1/call T1/call name
17.53 8015.00 8015.00 bcache_data
7.52 11455.00 3440.00 htab_find_slot_with_hash
7.31 14799.00 3344.00 msymbol_hash_iw
7.18 18082.00 3283.00 read_partial_die
5.13 20426.00 2344.00 hash
4.30 22392.00 1966.00 compare_psymbols
4.23 24328.00 1936.00 gnu_debuglink_crc32
3.92 26122.00 1794.00 read_attribute_value
3.67 27800.00 1678.00 htab_hash_string
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Huge slowdown since 6.0
2004-02-18 21:09 Huge slowdown since 6.0 Daniel Jacobowitz
@ 2004-02-18 21:31 ` David Carlton
2004-02-18 22:45 ` Kip Macy
2004-02-20 5:09 ` Daniel Jacobowitz
2004-02-19 1:59 ` Elena Zannoni
1 sibling, 2 replies; 29+ messages in thread
From: David Carlton @ 2004-02-18 21:31 UTC (permalink / raw)
To: gdb
On Wed, 18 Feb 2004 16:09:28 -0500, Daniel Jacobowitz <drow@false.org> said:
> The only reasonable explanation is that the number of global symbols has
> vastly increased. This appears to be the case. David, the blame appears to
> be yours, in dwarf2read.c revision 1.120:
> @@ -1519,14 +1556,16 @@ add_partial_symbol (struct partial_die_i
> /* For C++, these implicitly act as typedefs as well. */
> add_psymbol_to_list (actual_name, strlen (actual_name),
> VAR_DOMAIN, LOC_TYPEDEF,
> - &objfile->static_psymbols,
> + &objfile->global_psymbols,
> 0, (CORE_ADDR) 0, cu_language, objfile);
> }
> break;
> case DW_TAG_enumerator:
> add_psymbol_to_list (actual_name, strlen (actual_name),
> VAR_DOMAIN, LOC_CONST,
> - &objfile->static_psymbols,
> + cu_language == language_cplus
> + ? &objfile->static_psymbols
> + : &objfile->global_psymbols,
> 0, (CORE_ADDR) 0, cu_language, objfile);
> break;
> default:
> Could you re-explain the need for this change, please? You said:
> + /* NOTE: carlton/2003-11-10: C++ class symbols shouldn't
> + really ever be static objects: otherwise, if you try
> + to, say, break of a class's method and you're in a file
> + which doesn't mention that class, it won't work unless
> + the check for all static symbols in lookup_symbol_aux
> + saves you. See the OtherFileClass tests in
> + gdb.c++/namespace.exp. */
> +
> but is that also necessary for enumerators? As things stand, one
> large enum in a used header can lead to worse-than-linear slowdown
> of GDB startup for DWARF-2, and a couple megabytes of wasted memory.
Crap. Well, in some sense, enumerators really are global in C++: it's
illegal to have two different enums in the same scope that have an
enumerator with the same name. (I'm pretty sure.) So, in the
mythical future super-groovy-GDB where we coalesce all sorts of
type-related debug information across files, it would be nice if, in
the C++ case, enumerators were treated as global (and were coalesced).
Having said that, it should be the case that handling enumerators this
way is much less important than handling class symbols this way. I
can't quite envision the consequences of reverting the change for
enumerators; it will mean that you can't print out enumerators that
are defined in namespaces and that aren't in the debug info for the
current source file (if any), but that doesn't sound like too big a
deal to me.
David Carlton
carlton@kealia.com
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Huge slowdown since 6.0
2004-02-18 21:31 ` David Carlton
@ 2004-02-18 22:45 ` Kip Macy
2004-02-19 3:35 ` Daniel Jacobowitz
2004-02-20 5:09 ` Daniel Jacobowitz
1 sibling, 1 reply; 29+ messages in thread
From: Kip Macy @ 2004-02-18 22:45 UTC (permalink / raw)
To: David Carlton; +Cc: gdb
About a year ago our tools person added symbol-caching to our in-house
GDB tree. He happened to use an STL map, although there are certainly
more C-compliant ways. Prior to this change, developers had to use
pointer arithmetic in their macros to avoid repeated lookups or their
macros would run too SLOW. Would symbol-caching be something that would
make sense for mainline GDB?
-Kip
On Wed, 18 Feb 2004, David Carlton wrote:
> On Wed, 18 Feb 2004 16:09:28 -0500, Daniel Jacobowitz <drow@false.org> said:
>
> > The only reasonable explanation is that the number of global symbols has
> > vastly increased. This appears to be the case. David, the blame appears to
> > be yours, in dwarf2read.c revision 1.120:
>
> > @@ -1519,14 +1556,16 @@ add_partial_symbol (struct partial_die_i
> > /* For C++, these implicitly act as typedefs as well. */
> > add_psymbol_to_list (actual_name, strlen (actual_name),
> > VAR_DOMAIN, LOC_TYPEDEF,
> > - &objfile->static_psymbols,
> > + &objfile->global_psymbols,
> > 0, (CORE_ADDR) 0, cu_language, objfile);
> > }
> > break;
> > case DW_TAG_enumerator:
> > add_psymbol_to_list (actual_name, strlen (actual_name),
> > VAR_DOMAIN, LOC_CONST,
> > - &objfile->static_psymbols,
> > + cu_language == language_cplus
> > + ? &objfile->static_psymbols
> > + : &objfile->global_psymbols,
> > 0, (CORE_ADDR) 0, cu_language, objfile);
> > break;
> > default:
>
> > Could you re-explain the need for this change, please? You said:
>
> > + /* NOTE: carlton/2003-11-10: C++ class symbols shouldn't
> > + really ever be static objects: otherwise, if you try
> > + to, say, break of a class's method and you're in a file
> > + which doesn't mention that class, it won't work unless
> > + the check for all static symbols in lookup_symbol_aux
> > + saves you. See the OtherFileClass tests in
> > + gdb.c++/namespace.exp. */
> > +
>
> > but is that also necessary for enumerators? As things stand, one
> > large enum in a used header can lead to worse-than-linear slowdown
> > of GDB startup for DWARF-2, and a couple megabytes of wasted memory.
>
> Crap. Well, in some sense, enumerators really are global in C++: it's
> illegal to have two different enums in the same scope that have an
> enumerator with the same name. (I'm pretty sure.) So, in the
> mythical future super-groovy-GDB where we coalesce all sorts of
> type-related debug information across files, it would be nice if, in
> the C++ case, enumerators were treated as global (and were coalesced).
>
> Having said that, it should be the case that handling enumerators this
> way is much less important than handling class symbols this way. I
> can't quite envision the consequences of reverting the change for
> enumerators; it will mean that you can't print out enumerators that
> are defined in namespaces and that aren't in the debug info for the
> current source file (if any), but that doesn't sound like too big a
> deal to me.
>
> David Carlton
> carlton@kealia.com
>
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Huge slowdown since 6.0
2004-02-18 21:09 Huge slowdown since 6.0 Daniel Jacobowitz
2004-02-18 21:31 ` David Carlton
@ 2004-02-19 1:59 ` Elena Zannoni
2004-02-19 3:35 ` Daniel Jacobowitz
1 sibling, 1 reply; 29+ messages in thread
From: Elena Zannoni @ 2004-02-19 1:59 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: carlton, gdb
Daniel Jacobowitz writes:
> I finished prototyping my partial-symbol-sorting changes, as discussed on
> gdb-patches, and went to measure their impact. The results were a little
> confusing, but I've tracked them down. At the bottom of my message are
> profiling numbers if you want to see them. The summary is that I hope they
> won't be needed.
>
> Basically, the bottleneck in strcmp_iw_ordered that I am attacking was not
> there in 6.0. This baffled me. There were just as many psymbols and there
> should have been just as many calls; the change to use strcmp_iw_ordered
> predates 6.0.
How many psymbols do you have in the pst list of globals before and
after David's change? All you did was to time the times it took to
insert symbols and sort them, no lookups, right?
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Huge slowdown since 6.0
2004-02-19 1:59 ` Elena Zannoni
@ 2004-02-19 3:35 ` Daniel Jacobowitz
2004-02-19 3:58 ` Daniel Jacobowitz
0 siblings, 1 reply; 29+ messages in thread
From: Daniel Jacobowitz @ 2004-02-19 3:35 UTC (permalink / raw)
To: Elena Zannoni; +Cc: carlton, gdb
On Wed, Feb 18, 2004 at 08:54:54PM -0500, Elena Zannoni wrote:
> Daniel Jacobowitz writes:
> > I finished prototyping my partial-symbol-sorting changes, as discussed on
> > gdb-patches, and went to measure their impact. The results were a little
> > confusing, but I've tracked them down. At the bottom of my message are
> > profiling numbers if you want to see them. The summary is that I hope they
> > won't be needed.
> >
> > Basically, the bottleneck in strcmp_iw_ordered that I am attacking was not
> > there in 6.0. This baffled me. There were just as many psymbols and there
> > should have been just as many calls; the change to use strcmp_iw_ordered
> > predates 6.0.
>
>
> How many psymbols do you have in the pst list of globals before and
> after David's change? All you did was to time the times it took to
> insert symbols and sort them, no lookups, right?
That's right - just insertion and sorting. Lookups are fast; the
binary search isn't quite as nice as a hash table would be but it's
still pretty quick. It's just insertion that hurts us. Perhaps a more
efficient representation is on order.
GDB 6.0:
(gdb) p object_files.global_psymbols.size
$4 = 3264
(gdb) p object_files.static_psymbols.size
$5 = 835584
(gdb) p object_files.stats.n_psyms
$3 = 829406
GDB HEAD:
(gdb) p object_files.global_psymbols.size
$1 = 835584
(gdb) p object_files.static_psymbols.size
$2 = 417792
(gdb) p object_files.stats.n_psyms
$3 = 829406
Um... I'm not precisely sure why these numbers don't add up. I notice
they didn't before either.
By the way, do we even need the address field from general_symbol_info
in psymbols? I haven't checked thoroughly but I suspect that most of
the places we currently use it, the symtab will usually be read in
shortly afterwards anyway.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Huge slowdown since 6.0
2004-02-18 22:45 ` Kip Macy
@ 2004-02-19 3:35 ` Daniel Jacobowitz
2004-02-19 5:06 ` Kip Macy
0 siblings, 1 reply; 29+ messages in thread
From: Daniel Jacobowitz @ 2004-02-19 3:35 UTC (permalink / raw)
To: Kip Macy; +Cc: David Carlton, gdb
On Wed, Feb 18, 2004 at 02:44:56PM -0800, Kip Macy wrote:
> About a year ago our tools person added symbol-caching to our in-house
> GDB tree. He happened to use an STL map, although there are certainly
> more C-compliant ways. Prior to this change, developers had to use
> pointer arithmetic in their macros to avoid repeated lookups or their
> macros would run too SLOW. Would symbol-caching be something that would
> make sense for mainline GDB?
Maybe, but a year or two ago symbol lookup was a whole lot slower than
it is now. I suspect it would not make a lot of difference.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Huge slowdown since 6.0
2004-02-19 3:35 ` Daniel Jacobowitz
@ 2004-02-19 3:58 ` Daniel Jacobowitz
0 siblings, 0 replies; 29+ messages in thread
From: Daniel Jacobowitz @ 2004-02-19 3:58 UTC (permalink / raw)
To: gdb; +Cc: Elena Zannoni, carlton
Q:
On Wed, Feb 18, 2004 at 10:34:47PM -0500, Daniel Jacobowitz wrote:
> Um... I'm not precisely sure why these numbers don't add up. I notice
> they didn't before either.
A: The number of psymbols is list->next - list->list, not list->size.
The list is extended by doubling. Things add up fine.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Huge slowdown since 6.0
2004-02-19 3:35 ` Daniel Jacobowitz
@ 2004-02-19 5:06 ` Kip Macy
2004-02-19 15:40 ` Daniel Jacobowitz
0 siblings, 1 reply; 29+ messages in thread
From: Kip Macy @ 2004-02-19 5:06 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: David Carlton, gdb
Good to know. What has changed to speed up symbol lookup?
-Kip
On Wed, 18 Feb 2004, Daniel Jacobowitz wrote:
> On Wed, Feb 18, 2004 at 02:44:56PM -0800, Kip Macy wrote:
> > About a year ago our tools person added symbol-caching to our in-house
> > GDB tree. He happened to use an STL map, although there are certainly
> > more C-compliant ways. Prior to this change, developers had to use
> > pointer arithmetic in their macros to avoid repeated lookups or their
> > macros would run too SLOW. Would symbol-caching be something that would
> > make sense for mainline GDB?
>
> Maybe, but a year or two ago symbol lookup was a whole lot slower than
> it is now. I suspect it would not make a lot of difference.
>
> --
> Daniel Jacobowitz
> MontaVista Software Debian GNU/Linux Developer
>
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Huge slowdown since 6.0
2004-02-19 5:06 ` Kip Macy
@ 2004-02-19 15:40 ` Daniel Jacobowitz
0 siblings, 0 replies; 29+ messages in thread
From: Daniel Jacobowitz @ 2004-02-19 15:40 UTC (permalink / raw)
To: Kip Macy; +Cc: David Carlton, gdb
On Wed, Feb 18, 2004 at 09:06:34PM -0800, Kip Macy wrote:
> Good to know. What has changed to speed up symbol lookup?
Hash tables, mostly.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Huge slowdown since 6.0
2004-02-18 21:31 ` David Carlton
2004-02-18 22:45 ` Kip Macy
@ 2004-02-20 5:09 ` Daniel Jacobowitz
2004-02-20 16:42 ` Elena Zannoni
2004-02-20 16:52 ` David Carlton
1 sibling, 2 replies; 29+ messages in thread
From: Daniel Jacobowitz @ 2004-02-20 5:09 UTC (permalink / raw)
To: David Carlton; +Cc: gdb
On Wed, Feb 18, 2004 at 01:31:12PM -0800, David Carlton wrote:
> On Wed, 18 Feb 2004 16:09:28 -0500, Daniel Jacobowitz <drow@false.org> said:
>
> > The only reasonable explanation is that the number of global symbols has
> > vastly increased. This appears to be the case. David, the blame appears to
> > be yours, in dwarf2read.c revision 1.120:
>
> > @@ -1519,14 +1556,16 @@ add_partial_symbol (struct partial_die_i
> > /* For C++, these implicitly act as typedefs as well. */
> > add_psymbol_to_list (actual_name, strlen (actual_name),
> > VAR_DOMAIN, LOC_TYPEDEF,
> > - &objfile->static_psymbols,
> > + &objfile->global_psymbols,
> > 0, (CORE_ADDR) 0, cu_language, objfile);
> > }
> > break;
> > case DW_TAG_enumerator:
> > add_psymbol_to_list (actual_name, strlen (actual_name),
> > VAR_DOMAIN, LOC_CONST,
> > - &objfile->static_psymbols,
> > + cu_language == language_cplus
> > + ? &objfile->static_psymbols
> > + : &objfile->global_psymbols,
> > 0, (CORE_ADDR) 0, cu_language, objfile);
> > break;
> > default:
>
> > Could you re-explain the need for this change, please? You said:
>
> > + /* NOTE: carlton/2003-11-10: C++ class symbols shouldn't
> > + really ever be static objects: otherwise, if you try
> > + to, say, break of a class's method and you're in a file
> > + which doesn't mention that class, it won't work unless
> > + the check for all static symbols in lookup_symbol_aux
> > + saves you. See the OtherFileClass tests in
> > + gdb.c++/namespace.exp. */
> > +
>
> > but is that also necessary for enumerators? As things stand, one
> > large enum in a used header can lead to worse-than-linear slowdown
> > of GDB startup for DWARF-2, and a couple megabytes of wasted memory.
>
> Crap. Well, in some sense, enumerators really are global in C++: it's
> illegal to have two different enums in the same scope that have an
> enumerator with the same name. (I'm pretty sure.) So, in the
> mythical future super-groovy-GDB where we coalesce all sorts of
> type-related debug information across files, it would be nice if, in
> the C++ case, enumerators were treated as global (and were coalesced).
>
> Having said that, it should be the case that handling enumerators this
> way is much less important than handling class symbols this way. I
> can't quite envision the consequences of reverting the change for
> enumerators; it will mean that you can't print out enumerators that
> are defined in namespaces and that aren't in the debug info for the
> current source file (if any), but that doesn't sound like too big a
> deal to me.
OK, boot to the head time.
My testcase is in C.
These are all conditionalized on language_cplus.
How can they possibly be to blame? Well, they are. And reverting the
change for enumerators definitely won't do any harm. Take a look at
this, read it two or three times if necessary - it took me about a
dozen:
> > - &objfile->static_psymbols,
> > + cu_language == language_cplus
> > + ? &objfile->static_psymbols
> > + : &objfile->global_psymbols,
If I swap "static" and "global", it reduces GDB startup time by roughly
40% for glibc with debug information, which contains a lot of C
enumerators. I assume that is what you meant to do in the first place?
If so I can recover the speed hit for C for GDB 6.1, and then address
the larger issues with large numbers of global psymbols in HEAD after
we branch.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Huge slowdown since 6.0
2004-02-20 5:09 ` Daniel Jacobowitz
@ 2004-02-20 16:42 ` Elena Zannoni
2004-02-20 16:47 ` Daniel Jacobowitz
2004-02-20 17:01 ` Andrew Cagney
2004-02-20 16:52 ` David Carlton
1 sibling, 2 replies; 29+ messages in thread
From: Elena Zannoni @ 2004-02-20 16:42 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: David Carlton, gdb
Daniel Jacobowitz writes:
> How can they possibly be to blame? Well, they are. And reverting the
> change for enumerators definitely won't do any harm. Take a look at
> this, read it two or three times if necessary - it took me about a
> dozen:
>
> > > - &objfile->static_psymbols,
> > > + cu_language == language_cplus
> > > + ? &objfile->static_psymbols
> > > + : &objfile->global_psymbols,
>
> If I swap "static" and "global", it reduces GDB startup time by roughly
> 40% for glibc with debug information, which contains a lot of C
> enumerators. I assume that is what you meant to do in the first place?
> If so I can recover the speed hit for C for GDB 6.1, and then address
> the larger issues with large numbers of global psymbols in HEAD after
> we branch.
Another point in favor of the theory that conditional expressions are
bad.
This should be fine, consider it preapproved. However, what you are
really saying is that qsort performance is really bad in case we have
lots of symbols to sort. But how many symbols? You didn't post the
numbers.
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Huge slowdown since 6.0
2004-02-20 16:42 ` Elena Zannoni
@ 2004-02-20 16:47 ` Daniel Jacobowitz
2004-02-20 17:33 ` Elena Zannoni
2004-02-20 17:01 ` Andrew Cagney
1 sibling, 1 reply; 29+ messages in thread
From: Daniel Jacobowitz @ 2004-02-20 16:47 UTC (permalink / raw)
To: Elena Zannoni; +Cc: David Carlton, gdb
On Fri, Feb 20, 2004 at 11:37:48AM -0500, Elena Zannoni wrote:
> Daniel Jacobowitz writes:
> > How can they possibly be to blame? Well, they are. And reverting the
> > change for enumerators definitely won't do any harm. Take a look at
> > this, read it two or three times if necessary - it took me about a
> > dozen:
> >
> > > > - &objfile->static_psymbols,
> > > > + cu_language == language_cplus
> > > > + ? &objfile->static_psymbols
> > > > + : &objfile->global_psymbols,
> >
> > If I swap "static" and "global", it reduces GDB startup time by roughly
> > 40% for glibc with debug information, which contains a lot of C
> > enumerators. I assume that is what you meant to do in the first place?
> > If so I can recover the speed hit for C for GDB 6.1, and then address
> > the larger issues with large numbers of global psymbols in HEAD after
> > we branch.
>
> Another point in favor of the theory that conditional expressions are
> bad.
>
> This should be fine, consider it preapproved. However, what you are
> really saying is that qsort performance is really bad in case we have
> lots of symbols to sort. But how many symbols? You didn't post the
> numbers.
OK, I'll post it to gdb-patches and check it in, later today.
What numbers would you like besides these? I can generate anything else
you're interested in.
http://sources.redhat.com/ml/gdb/2004-02/msg00236.html
The list padding makes those numbers inexact, but the gist is: about
3200 global symbols with enumerators static, and about 700,000 with
them global.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Huge slowdown since 6.0
2004-02-20 5:09 ` Daniel Jacobowitz
2004-02-20 16:42 ` Elena Zannoni
@ 2004-02-20 16:52 ` David Carlton
2004-02-20 16:58 ` Daniel Jacobowitz
2004-02-20 17:35 ` Elena Zannoni
1 sibling, 2 replies; 29+ messages in thread
From: David Carlton @ 2004-02-20 16:52 UTC (permalink / raw)
To: gdb
On Fri, 20 Feb 2004 00:09:06 -0500, Daniel Jacobowitz <drow@false.org> said:
> My testcase is in C.
> These are all conditionalized on language_cplus.
> How can they possibly be to blame? Well, they are. And reverting the
> change for enumerators definitely won't do any harm. Take a look at
> this, read it two or three times if necessary - it took me about a
> dozen:
>> > - &objfile->static_psymbols,
>> > + cu_language == language_cplus
>> > + ? &objfile->static_psymbols
>> > + : &objfile->global_psymbols,
> If I swap "static" and "global", it reduces GDB startup time by roughly
> 40% for glibc with debug information, which contains a lot of C
> enumerators. I assume that is what you meant to do in the first
> place?
Um, yeah. Oops. That would qualify as an obvious fix.
There's one other interesting point here - where exactly is the
slowdown coming from? After all, we generate the same number of
searches, and lookup_symbol can potentially look at all the static
psymbols just like it could look at all the global psymbols. Not only
that, but looking at the static psymbols is vastly slower than looking
at the global psymbols (for no good reason, as far as I know, but
that's a separate issue; lookup_partial_symbol has issues).
But I suppose the point is that looking at all the static psymbols is
only a very last resort in lookup_symbol, so (as long as the symbol
you're looking for actually exists) it wouldn't get called very often.
Or is there something else that I'm missing?
David Carlton
carlton@kealia.com
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Huge slowdown since 6.0
2004-02-20 16:52 ` David Carlton
@ 2004-02-20 16:58 ` Daniel Jacobowitz
2004-02-20 17:00 ` David Carlton
2004-02-20 17:35 ` Elena Zannoni
1 sibling, 1 reply; 29+ messages in thread
From: Daniel Jacobowitz @ 2004-02-20 16:58 UTC (permalink / raw)
To: gdb
On Fri, Feb 20, 2004 at 08:52:35AM -0800, David Carlton wrote:
> There's one other interesting point here - where exactly is the
> slowdown coming from? After all, we generate the same number of
> searches, and lookup_symbol can potentially look at all the static
> psymbols just like it could look at all the global psymbols. Not only
> that, but looking at the static psymbols is vastly slower than looking
> at the global psymbols (for no good reason, as far as I know, but
> that's a separate issue; lookup_partial_symbol has issues).
>
> But I suppose the point is that looking at all the static psymbols is
> only a very last resort in lookup_symbol, so (as long as the symbol
> you're looking for actually exists) it wouldn't get called very often.
>
> Or is there something else that I'm missing?
I'm not even getting to the point where we do searches. See
sort_pst_symbols for the issue.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Huge slowdown since 6.0
2004-02-20 16:58 ` Daniel Jacobowitz
@ 2004-02-20 17:00 ` David Carlton
0 siblings, 0 replies; 29+ messages in thread
From: David Carlton @ 2004-02-20 17:00 UTC (permalink / raw)
To: gdb
On Fri, 20 Feb 2004 11:58:45 -0500, Daniel Jacobowitz <drow@false.org> said:
> On Fri, Feb 20, 2004 at 08:52:35AM -0800, David Carlton wrote:
>> There's one other interesting point here - where exactly is the
>> slowdown coming from? After all, we generate the same number of
>> searches, and lookup_symbol can potentially look at all the static
>> psymbols just like it could look at all the global psymbols. Not
>> only that, but looking at the static psymbols is vastly slower than
>> looking at the global psymbols (for no good reason, as far as I
>> know, but that's a separate issue; lookup_partial_symbol has
>> issues).
>>
>> But I suppose the point is that looking at all the static psymbols is
>> only a very last resort in lookup_symbol, so (as long as the symbol
>> you're looking for actually exists) it wouldn't get called very often.
>>
>> Or is there something else that I'm missing?
> I'm not even getting to the point where we do searches. See
> sort_pst_symbols for the issue.
Oh, interesting. Hmm; that puts a different spin on things.
David Carlton
carlton@kealia.com
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Huge slowdown since 6.0
2004-02-20 16:42 ` Elena Zannoni
2004-02-20 16:47 ` Daniel Jacobowitz
@ 2004-02-20 17:01 ` Andrew Cagney
2004-02-20 17:05 ` Daniel Jacobowitz
2004-02-20 17:45 ` Elena Zannoni
1 sibling, 2 replies; 29+ messages in thread
From: Andrew Cagney @ 2004-02-20 17:01 UTC (permalink / raw)
To: Elena Zannoni, Daniel Jacobowitz, David Carlton; +Cc: gdb
> Daniel Jacobowitz writes:
> > How can they possibly be to blame? Well, they are. And reverting the
> > change for enumerators definitely won't do any harm. Take a look at
> > this, read it two or three times if necessary - it took me about a
> > dozen:
> >
> > > > - &objfile->static_psymbols,
> > > > + cu_language == language_cplus
> > > > + ? &objfile->static_psymbols
> > > > + : &objfile->global_psymbols,
> >
> > If I swap "static" and "global", it reduces GDB startup time by roughly
> > 40% for glibc with debug information, which contains a lot of C
> > enumerators. I assume that is what you meant to do in the first place?
> > If so I can recover the speed hit for C for GDB 6.1, and then address
> > the larger issues with large numbers of global psymbols in HEAD after
> > we branch.
>
> Another point in favor of the theory that conditional expressions are
> bad.
>
> This should be fine, consider it preapproved. However, what you are
> really saying is that qsort performance is really bad in case we have
> lots of symbols to sort. But how many symbols? You didn't post the
> numbers.
Hmm, begs a few questions:
- why do we load the symbols during startup?
Load globals on demand?
- why do we sort the symbols during startup?
Use a hash (so that break main is fast) and sort when (break main<tab>
is entered?)
- why don't we do more while GDB is twiddling its thumbs in the event
loop event loop?
Andrew
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Huge slowdown since 6.0
2004-02-20 17:01 ` Andrew Cagney
@ 2004-02-20 17:05 ` Daniel Jacobowitz
2004-02-20 17:45 ` Elena Zannoni
1 sibling, 0 replies; 29+ messages in thread
From: Daniel Jacobowitz @ 2004-02-20 17:05 UTC (permalink / raw)
To: Andrew Cagney; +Cc: Elena Zannoni, David Carlton, gdb
On Fri, Feb 20, 2004 at 12:01:44PM -0500, Andrew Cagney wrote:
> Hmm, begs a few questions:
>
> - why do we load the symbols during startup?
> Load globals on demand?
What sort of demand do you have in mind?
> - why do we sort the symbols during startup?
> Use a hash (so that break main is fast) and sort when (break main<tab>
> is entered?)
Partial symbols are the only remaining thing that gets sorted. Fixing
this is somewhat complicated; it was the first option I looked at. My
preferred first step is to not keep any symbol address information in
partial symbols, after which I think it will be easier; this is a
long-term cleanup.
> - why don't we do more while GDB is twiddling its thumbs in the event
> loop event loop?
Hmm.... that's pretty complicated to implement. It would require doing
things in small chunks and handling interruption gracefully. The
problem is, at the first symbol lookup, we will probably need to have
all the symbols...
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Huge slowdown since 6.0
2004-02-20 16:47 ` Daniel Jacobowitz
@ 2004-02-20 17:33 ` Elena Zannoni
0 siblings, 0 replies; 29+ messages in thread
From: Elena Zannoni @ 2004-02-20 17:33 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: Elena Zannoni, David Carlton, gdb
Daniel Jacobowitz writes:
> On Fri, Feb 20, 2004 at 11:37:48AM -0500, Elena Zannoni wrote:
> > Daniel Jacobowitz writes:
> > > How can they possibly be to blame? Well, they are. And reverting the
> > > change for enumerators definitely won't do any harm. Take a look at
> > > this, read it two or three times if necessary - it took me about a
> > > dozen:
> > >
> > > > > - &objfile->static_psymbols,
> > > > > + cu_language == language_cplus
> > > > > + ? &objfile->static_psymbols
> > > > > + : &objfile->global_psymbols,
> > >
> > > If I swap "static" and "global", it reduces GDB startup time by roughly
> > > 40% for glibc with debug information, which contains a lot of C
> > > enumerators. I assume that is what you meant to do in the first place?
> > > If so I can recover the speed hit for C for GDB 6.1, and then address
> > > the larger issues with large numbers of global psymbols in HEAD after
> > > we branch.
> >
> > Another point in favor of the theory that conditional expressions are
> > bad.
> >
> > This should be fine, consider it preapproved. However, what you are
> > really saying is that qsort performance is really bad in case we have
> > lots of symbols to sort. But how many symbols? You didn't post the
> > numbers.
>
> OK, I'll post it to gdb-patches and check it in, later today.
>
> What numbers would you like besides these? I can generate anything else
> you're interested in.
> http://sources.redhat.com/ml/gdb/2004-02/msg00236.html
>
> The list padding makes those numbers inexact, but the gist is: about
> 3200 global symbols with enumerators static, and about 700,000 with
> them global.
yeah, these ones. Wow.
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Huge slowdown since 6.0
2004-02-20 16:52 ` David Carlton
2004-02-20 16:58 ` Daniel Jacobowitz
@ 2004-02-20 17:35 ` Elena Zannoni
1 sibling, 0 replies; 29+ messages in thread
From: Elena Zannoni @ 2004-02-20 17:35 UTC (permalink / raw)
To: David Carlton; +Cc: gdb
David Carlton writes:
> On Fri, 20 Feb 2004 00:09:06 -0500, Daniel Jacobowitz <drow@false.org> said:
> > My testcase is in C.
>
> > These are all conditionalized on language_cplus.
>
> > How can they possibly be to blame? Well, they are. And reverting the
> > change for enumerators definitely won't do any harm. Take a look at
> > this, read it two or three times if necessary - it took me about a
> > dozen:
>
> >> > - &objfile->static_psymbols,
> >> > + cu_language == language_cplus
> >> > + ? &objfile->static_psymbols
> >> > + : &objfile->global_psymbols,
>
> > If I swap "static" and "global", it reduces GDB startup time by roughly
> > 40% for glibc with debug information, which contains a lot of C
> > enumerators. I assume that is what you meant to do in the first
> > place?
>
> Um, yeah. Oops. That would qualify as an obvious fix.
>
> There's one other interesting point here - where exactly is the
> slowdown coming from? After all, we generate the same number of
> searches, and lookup_symbol can potentially look at all the static
> psymbols just like it could look at all the global psymbols. Not only
> that, but looking at the static psymbols is vastly slower than looking
> at the global psymbols (for no good reason, as far as I know, but
> that's a separate issue; lookup_partial_symbol has issues).
>
> But I suppose the point is that looking at all the static psymbols is
> only a very last resort in lookup_symbol, so (as long as the symbol
> you're looking for actually exists) it wouldn't get called very often.
>
> Or is there something else that I'm missing?
No lookup yet. Only reading the debuginfo and sorting *only the globals*.
Daniel profiled only the reading of the psymbols part.
It threw off me for a while, before I remembered that we only sort the
globals psymbols.
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Huge slowdown since 6.0
2004-02-20 17:01 ` Andrew Cagney
2004-02-20 17:05 ` Daniel Jacobowitz
@ 2004-02-20 17:45 ` Elena Zannoni
2004-02-20 18:07 ` Andrew Cagney
2004-02-21 2:18 ` Daniel Jacobowitz
1 sibling, 2 replies; 29+ messages in thread
From: Elena Zannoni @ 2004-02-20 17:45 UTC (permalink / raw)
To: Andrew Cagney; +Cc: Elena Zannoni, Daniel Jacobowitz, David Carlton, gdb
Andrew Cagney writes:
> > Daniel Jacobowitz writes:
> > > How can they possibly be to blame? Well, they are. And reverting the
> > > change for enumerators definitely won't do any harm. Take a look at
> > > this, read it two or three times if necessary - it took me about a
> > > dozen:
> > >
> > > > > - &objfile->static_psymbols,
> > > > > + cu_language == language_cplus
> > > > > + ? &objfile->static_psymbols
> > > > > + : &objfile->global_psymbols,
> > >
> > > If I swap "static" and "global", it reduces GDB startup time by roughly
> > > 40% for glibc with debug information, which contains a lot of C
> > > enumerators. I assume that is what you meant to do in the first place?
> > > If so I can recover the speed hit for C for GDB 6.1, and then address
> > > the larger issues with large numbers of global psymbols in HEAD after
> > > we branch.
> >
> > Another point in favor of the theory that conditional expressions are
> > bad.
> >
> > This should be fine, consider it preapproved. However, what you are
> > really saying is that qsort performance is really bad in case we have
> > lots of symbols to sort. But how many symbols? You didn't post the
> > numbers.
>
> Hmm, begs a few questions:
sorry, I am talking about partial symbols. It's not clear from the above.
>
> - why do we load the symbols during startup?
> Load globals on demand?
> - why do we sort the symbols during startup?
> Use a hash (so that break main is fast) and sort when (break main<tab>
> is entered?)
> - why don't we do more while GDB is twiddling its thumbs in the event
> loop event loop?
The thing that I am curious about is to see how early into a regular
debug session we build the symtabs. I.e. I am afraid that any
reference to any symbol from the command line makes the whole lot
expand anyway. The answer to this may help answer the question whether
we really need a two tier symbol table system, or if there is another
way of solving the same problem. While cleaning up the obstack stuff,
it became obvious that the intent was for the psymtabs to go away once
expanded into full symtabs, but this was never implemented.
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Huge slowdown since 6.0
2004-02-20 17:45 ` Elena Zannoni
@ 2004-02-20 18:07 ` Andrew Cagney
2004-02-20 18:24 ` Daniel Jacobowitz
2004-02-21 2:18 ` Daniel Jacobowitz
1 sibling, 1 reply; 29+ messages in thread
From: Andrew Cagney @ 2004-02-20 18:07 UTC (permalink / raw)
To: Elena Zannoni; +Cc: Daniel Jacobowitz, David Carlton, gdb
> > Hmm, begs a few questions:
>
> sorry, I am talking about partial symbols. It's not clear from the above.
[psymbols, symbols, same question :-)]
> >
> > - why do we load the symbols during startup?
> > Load globals on demand?
Daniel wrote:
> What sort of demand do you have in mind?
The very first lookup_symbol_by_name().
At present core gdb contains significant chunks of logic intended to out
wit the symbol table. core-gdb should instead just ask for exactly what
it needs and let the symbol table decide if/when something should be
pulled in.
> > - why do we sort the symbols during startup?
> > Use a hash (so that break main is fast) and sort when (break main<tab>
> > is entered?)
> > - why don't we do more while GDB is twiddling its thumbs in the event
> > loop event loop?
Daniel writes:
> Hmm.... that's pretty complicated to implement. It would require doing
> things in small chunks and handling interruption gracefully. The
> problem is, at the first symbol lookup, we will probably need to have
> all the symbols...
The current behavior isn't too friendly either mind. Given a slow
loading symbol table the users only option is "take an early lunch".
Cntrl-c, if it worked, would just abort the load :-(
Even if we start out with on-demand, it should work better. Given:
$ gdb foo
(gdb) break main
(gdb) run
why is GDB loading glibc's symbols?
> The thing that I am curious about is to see how early into a regular
> debug session we build the symtabs. I.e. I am afraid that any
> reference to any symbol from the command line makes the whole lot
> expand anyway. The answer to this may help answer the question whether
> we really need a two tier symbol table system, or if there is another
> way of solving the same problem. While cleaning up the obstack stuff,
> it became obvious that the intent was for the psymtabs to go away once
> expanded into full symtabs, but this was never implemented.
enjoy,
Andrew
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Huge slowdown since 6.0
2004-02-20 18:07 ` Andrew Cagney
@ 2004-02-20 18:24 ` Daniel Jacobowitz
2004-02-20 18:45 ` Andrew Cagney
0 siblings, 1 reply; 29+ messages in thread
From: Daniel Jacobowitz @ 2004-02-20 18:24 UTC (permalink / raw)
To: Andrew Cagney; +Cc: Elena Zannoni, David Carlton, gdb
On Fri, Feb 20, 2004 at 01:07:46PM -0500, Andrew Cagney wrote:
> Even if we start out with on-demand, it should work better. Given:
>
> $ gdb foo
> (gdb) break main
> (gdb) run
>
> why is GDB loading glibc's symbols?
Main might be a function defined in a shared library. Even if we found
a definition in the executable, it might be a PLT loading slot. KDE
on i386 will demonstrate this exact behavior.
IOW, I don't think there is anything we can do without loading symbols
as soon as objects are available.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Huge slowdown since 6.0
2004-02-20 18:24 ` Daniel Jacobowitz
@ 2004-02-20 18:45 ` Andrew Cagney
2004-02-20 18:48 ` Daniel Jacobowitz
2004-02-21 9:04 ` Eli Zaretskii
0 siblings, 2 replies; 29+ messages in thread
From: Andrew Cagney @ 2004-02-20 18:45 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: Elena Zannoni, David Carlton, gdb
> On Fri, Feb 20, 2004 at 01:07:46PM -0500, Andrew Cagney wrote:
>
>>> Even if we start out with on-demand, it should work better. Given:
>>>
>>> $ gdb foo
>>> (gdb) break main
>>> (gdb) run
>>>
>>> why is GDB loading glibc's symbols?
>
>
> Main might be a function defined in a shared library. Even if we found
> a definition in the executable, it might be a PLT loading slot. KDE
> on i386 will demonstrate this exact behavior.
It's been suggested to me that we should create a hacked gdb that
records all commands et.al. to a file, and then offers to send them to
us. That way we know what is, rather than what might be.
If we knew for instance that only 10% of users set breakpoints outside
of the main executible, then we'd also know that we were frustrating 90%
of users by making them sit around waiting for needless symbol table
reads :-(
On the other hand, if we knew that the first thing people did was:
(gdb) break <tab>
we'd have an entirely different problem.
Andrew
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Huge slowdown since 6.0
2004-02-20 18:45 ` Andrew Cagney
@ 2004-02-20 18:48 ` Daniel Jacobowitz
2004-02-21 9:21 ` Eli Zaretskii
2004-02-21 9:04 ` Eli Zaretskii
1 sibling, 1 reply; 29+ messages in thread
From: Daniel Jacobowitz @ 2004-02-20 18:48 UTC (permalink / raw)
To: Andrew Cagney; +Cc: Elena Zannoni, David Carlton, gdb
On Fri, Feb 20, 2004 at 01:45:40PM -0500, Andrew Cagney wrote:
> >On Fri, Feb 20, 2004 at 01:07:46PM -0500, Andrew Cagney wrote:
> >
> >>>Even if we start out with on-demand, it should work better. Given:
> >>>
> >>> $ gdb foo
> >>> (gdb) break main
> >>> (gdb) run
> >>>
> >>>why is GDB loading glibc's symbols?
> >
> >
> >Main might be a function defined in a shared library. Even if we found
> >a definition in the executable, it might be a PLT loading slot. KDE
> >on i386 will demonstrate this exact behavior.
>
> It's been suggested to me that we should create a hacked gdb that
> records all commands et.al. to a file, and then offers to send them to
> us. That way we know what is, rather than what might be.
>
> If we knew for instance that only 10% of users set breakpoints outside
> of the main executible, then we'd also know that we were frustrating 90%
> of users by making them sit around waiting for needless symbol table
> reads :-(
>
> On the other hand, if we knew that the first thing people did was:
> (gdb) break <tab>
> we'd have an entirely different problem.
My point is that whether or not "break main" shows up as resolving to
the main executable, to get it right in the general case, we also need
shared library symbols. I discussed this at length in the last thread
about multiple-address breakpoints. For main in particular maybe it's
a non-issue, but not for any other function.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Huge slowdown since 6.0
2004-02-20 17:45 ` Elena Zannoni
2004-02-20 18:07 ` Andrew Cagney
@ 2004-02-21 2:18 ` Daniel Jacobowitz
1 sibling, 0 replies; 29+ messages in thread
From: Daniel Jacobowitz @ 2004-02-21 2:18 UTC (permalink / raw)
To: Elena Zannoni; +Cc: Andrew Cagney, David Carlton, gdb
On Fri, Feb 20, 2004 at 12:41:04PM -0500, Elena Zannoni wrote:
> The thing that I am curious about is to see how early into a regular
> debug session we build the symtabs. I.e. I am afraid that any
> reference to any symbol from the command line makes the whole lot
> expand anyway. The answer to this may help answer the question whether
> we really need a two tier symbol table system, or if there is another
> way of solving the same problem. While cleaning up the obstack stuff,
> it became obvious that the intent was for the psymtabs to go away once
> expanded into full symtabs, but this was never implemented.
From the last time I looked at this issue (a while ago, now): when a
symbol is referenced on the command line we generally build symtabs for
the symbol containing it. We do not build all symtabs for its object;
we used to do that for some C++ operations (overload checking maybe?)
and it was extremely noticeable.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Huge slowdown since 6.0
2004-02-20 18:45 ` Andrew Cagney
2004-02-20 18:48 ` Daniel Jacobowitz
@ 2004-02-21 9:04 ` Eli Zaretskii
1 sibling, 0 replies; 29+ messages in thread
From: Eli Zaretskii @ 2004-02-21 9:04 UTC (permalink / raw)
To: Andrew Cagney; +Cc: drow, ezannoni, carlton, gdb
> Date: Fri, 20 Feb 2004 13:45:40 -0500
> From: Andrew Cagney <cagney@gnu.org>
>
> If we knew for instance that only 10% of users set breakpoints outside
> of the main executible, then we'd also know that we were frustrating 90%
> of users by making them sit around waiting for needless symbol table
> reads :-(
I think we can say we know this already. I'm quite sure that the
number of users who set breakpoints outside their program's code is
miniscule, much less than 10%.
> On the other hand, if we knew that the first thing people did was:
> (gdb) break <tab>
> we'd have an entirely different problem.
I think "break TAB" is very rare. But "info address", "info symbol",
and their ilk might be much more popular. However, it is IMHO
entirely reasonable to load the full symbol table when such commands
are issued. I'd even print a message, something like
Loading symbols for your_monster_proggy; this could take a while..."
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Huge slowdown since 6.0
2004-02-20 18:48 ` Daniel Jacobowitz
@ 2004-02-21 9:21 ` Eli Zaretskii
0 siblings, 0 replies; 29+ messages in thread
From: Eli Zaretskii @ 2004-02-21 9:21 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: cagney, ezannoni, carlton, gdb
> Date: Fri, 20 Feb 2004 13:48:47 -0500
> From: Daniel Jacobowitz <drow@false.org>
>
> My point is that whether or not "break main" shows up as resolving to
> the main executable, to get it right in the general case, we also need
> shared library symbols.
Being relatively ignorant about the symtab issues, I might be missing
something, but my naive take of this is: couldn't we load the library
symbols only if the symbol FOO from a command such as "break FOO" is
not found in the main executable?
As for the shared libraries case, we could add start by loading only
user shared libraries, leaving out the system libraries. A list of
library names known to be system libraries plus some simple logic
could accomplish that, I think.
In general, it seems to me that if a symbol typed by the user is found
neither in the executable nor in the non-system shared libraries used
by the program, that symbol name is more likely a typo than a symbol
the user really wants. So I'd even suggest asking for confirmation
before loading the system libraries (we could have a `set' command to
avoid the confirmation, for those brave souls that debug system
libraries).
For example, even in Andrew's extreme case of "break TAB", wouldn't it
make more sense to print only the names that do not belong to the
system libraries? Do we really think that the user wants to see names
like "__exit" or "__libc_init" or "____strtod_l_internal"?
> I discussed this at length in the last thread about multiple-address
> breakpoints.
If that discussion answers the questions I asked above, could you
please point me to the URL(s) of the relevant message(s), so that you
would not need to repeat them?
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Huge slowdown since 6.0
2004-02-20 19:57 Michael Elizabeth Chastain
@ 2004-02-23 19:22 ` Andrew Cagney
0 siblings, 0 replies; 29+ messages in thread
From: Andrew Cagney @ 2004-02-23 19:22 UTC (permalink / raw)
To: Michael Elizabeth Chastain; +Cc: drow, carlton, ezannoni, gdb
> ac> It's been suggested to me that we should create a hacked gdb that
> ac> records all commands et.al. to a file, and then offers to send them to
> ac> us. That way we know what is, rather than what might be.
>
> I think we can do this just with doco. In the doco that says how
> to report bugs, add some basic instructions on the "script" command.
True, or even just by looking at the bug reports.
Andrew
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Huge slowdown since 6.0
@ 2004-02-20 19:57 Michael Elizabeth Chastain
2004-02-23 19:22 ` Andrew Cagney
0 siblings, 1 reply; 29+ messages in thread
From: Michael Elizabeth Chastain @ 2004-02-20 19:57 UTC (permalink / raw)
To: cagney, drow; +Cc: carlton, ezannoni, gdb
ac> It's been suggested to me that we should create a hacked gdb that
ac> records all commands et.al. to a file, and then offers to send them to
ac> us. That way we know what is, rather than what might be.
I think we can do this just with doco. In the doco that says how
to report bugs, add some basic instructions on the "script" command.
Michael C
^ permalink raw reply [flat|nested] 29+ messages in thread
end of thread, other threads:[~2004-02-23 19:22 UTC | newest]
Thread overview: 29+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-02-18 21:09 Huge slowdown since 6.0 Daniel Jacobowitz
2004-02-18 21:31 ` David Carlton
2004-02-18 22:45 ` Kip Macy
2004-02-19 3:35 ` Daniel Jacobowitz
2004-02-19 5:06 ` Kip Macy
2004-02-19 15:40 ` Daniel Jacobowitz
2004-02-20 5:09 ` Daniel Jacobowitz
2004-02-20 16:42 ` Elena Zannoni
2004-02-20 16:47 ` Daniel Jacobowitz
2004-02-20 17:33 ` Elena Zannoni
2004-02-20 17:01 ` Andrew Cagney
2004-02-20 17:05 ` Daniel Jacobowitz
2004-02-20 17:45 ` Elena Zannoni
2004-02-20 18:07 ` Andrew Cagney
2004-02-20 18:24 ` Daniel Jacobowitz
2004-02-20 18:45 ` Andrew Cagney
2004-02-20 18:48 ` Daniel Jacobowitz
2004-02-21 9:21 ` Eli Zaretskii
2004-02-21 9:04 ` Eli Zaretskii
2004-02-21 2:18 ` Daniel Jacobowitz
2004-02-20 16:52 ` David Carlton
2004-02-20 16:58 ` Daniel Jacobowitz
2004-02-20 17:00 ` David Carlton
2004-02-20 17:35 ` Elena Zannoni
2004-02-19 1:59 ` Elena Zannoni
2004-02-19 3:35 ` Daniel Jacobowitz
2004-02-19 3:58 ` Daniel Jacobowitz
2004-02-20 19:57 Michael Elizabeth Chastain
2004-02-23 19:22 ` Andrew Cagney
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox