This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFA 08/15] Remove readin and compunit_symtab fields from psymtab
- From: Simon Marchi <simark at simark dot ca>
- To: Tom Tromey <tom at tromey dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Sun, 7 Oct 2018 18:04:11 -0400
- Subject: Re: [RFA 08/15] Remove readin and compunit_symtab fields from psymtab
- References: <20180510222357.27332-1-tom@tromey.com> <20180510222357.27332-9-tom@tromey.com> <5f8f38c4-8b4b-9fea-b9f2-7c69758a09c2@simark.ca> <87lg7mi5al.fsf@tromey.com> <87zhvreujr.fsf@tromey.com>
On 2018-10-05 9:24 p.m., Tom Tromey wrote:
>>>>>> "Tom" == Tom Tromey <tom@tromey.com> writes:
>
>>>>>> "Simon" == Simon Marchi <simark@simark.ca> writes:
> Simon> As Pedro pointed out a few times, unordered_map is an hash map with open
> Simon> hashing. So we change what was previously a single pointer dereference
> Simon> to a lookup in a hash table, followed with a linear search in a linked
> Simon> list. If this map is looked up very frequently, maybe we should consider
> Simon> using an htab_t instead? Some profiling data would help, but it seems
> Simon> like psymtab_read_in_p is called quite a bit when looking up symbols...
>
> [...]
>
> Tom> I still haven't tried any performance measurements.
> Tom> I'm not quite sure what to try.
>
> I ran the gdb.perf tests and on some tests, it seems that the results
> are within the noise; but on backtrace (2048) and skip-function-3000 (4000)
> gdb is about 4% slower. I don't know if this is enough to worry about.
>
> Tom
>
That sounds like a reasonable trade-off in exchange for the feature of decoupling
psymtabs from objfiles. Perhaps we can put it on the list of "candidates for htab_t"
(could be a comment next to the field), for when we finally bring the C++ wrappers
from gcc :).
Simon