Re: question about expand_symtabs_matching()

[Tom Tromey <tom@tromey.com>]

Tom> Nope, but then again it isn't called in this scenario; at least not if
Tom> "some-file.c" exists.

Hannes> I should have clarified that I'm currently investigating why
Hannes> *pending* breakpoints slow down gdb so much.

Ok.  It's been a while, but IIRC in some cases linespec can't decide how
to parse a given string until it has seen some match.  So, sometimes
re-setting pending breakpoint can be more expensive.

For example I think gdb can't tell the difference between
"break filename:function" and "break function:label".

This is addressed by the "explicit locations" work, though I don't think
this work extends all the way to fine-grained breakpoint re-setting.

Personally I'd be fine with changing the syntax of the more obscure
linespecs ("function:label" is probably not used much in practice) in
order to make the parsing more sane, if it had a performance benefit
here.  But that's just me.

Also, a negative result is still a parse result; so if a linespec
understood which objfiles had been searched, it could still easily skip
this work on dlopen or dlclose.

Hannes> Similar, for the case of a simple function name as pending breakpoint,
Hannes> it's cp_canonicalize_string_no_typedefs() called by find_linespec_symbols(),
Hannes> that's taking most of the time.
Hannes> And I'm wondering if this call is necessary if you only use the function name
Hannes> without arguments (like 'function' or Class::member_function).

I doubt it's needed but on the other hand it may not really save much.
Maybe one way to do the experiment is check the string for
non-identifier characters before trying to canonicalize it.

Hannes> If you are interested, I could also send you the profiling flamegraphs.

It's an area I'm interested in but I'm not actively working there right
now.  If you're interested at all in gdb development ... on the one hand
tackling linespec caching is maybe a difficult project, but on the other
hand it seems fun :-)

Tom