Re: [RFA libiberty, gdb] Add hashtab support to filename_ncmp.c and use it in gdb.

[Doug Evans <dje@google.com>]

On Fri, Jul 13, 2012 at 11:52 AM, Doug Evans <dje@google.com> wrote:
> Hi.  "ping" [for the libiberty part]
>
> [The gdb part needs to be updated due to recent changes there, but I'm
> going to wait until the libiberty part is approved.]
>
> On Mon, Jul 9, 2012 at 11:10 AM, Doug Evans <dje@google.com> wrote:
>> Hi.
>>
>> filename_seen in gdb does a linear search, this patch changes it
>> to use a hash table.
>>
>> Ok to check in?
>>
>> I couldn't think of a good reason to put filename_hash,filename_eq in gdb,
>> and I like placing them close to where hashtab.c and filename_cmp are defined.
>> I also couldn't think of a sufficient reason to put them in a file by
>> themselves.  Ergo adding them to filename_cmp.c, filenames.h.
>> [It's possible there's a program that uses filename_cmp and already
>> defines functions with the same names (thus this will introduce a build
>> failure), but that's always a risk.  I couldn't find any in gdb,binutils,gcc.
>> Technically speaking, it's also possible that adding the #include "hashtab.h"
>> to filenames.h could introduce a build failure (e.g., some file has a static
>> symbol that collides with one used in hashtab.h).  I'm hoping that's more of
>> a theoretical concern.]
>>
>> 2012-07-09  Doug Evans  <dje@google.com>
>>
>>         include/
>>         * filenames.h: #include "hashtab.h".
>>         (filename_hash, filename_eq): Declare.
>>
>>         libiberty/
>>         * filename_cmp.c (filename_hash, filename_eq): New functions.
>>
>>         gdb/
>>         * symtab.c (filename_seen): Rewrite to use a hash table.

With the libiberty part done, here's the updated gdb side.

As data, using my standard large app for exercising gdb issues, and
after running it a few times to warm the disk cache (for the fullname
conversion):

gdb $program # uses .gdb_index v7
(gdb) mt time 1
(gdb) info sources #1
(gdb) info sources #2

Before (best of 3):
#1: 18.100000 (cpu), 18.666510 (wall)
#2: 7.580000 (cpu), 7.936617 (wall)

After (best of 3):
#1: 10.060000 (cpu), 10.912673 (wall)
#2: 0.280000 (cpu), 2.746012 (wall)

Ok to check in?

2012-07-13  Doug Evans  <dje@google.com>

        * symtab.c (filename_seen_cache): Delete members "tab_alloc_size",
        "tab_cur_size".  Change member "tab" to be a htab_t.
        (create_filename_seen_cache): Update.
        (clear_filename_seen_cache, delete_filename_seen_cache): Update.
        (filename_seen): Update.