.gdb_index prod perf regression: find before insert in unordered_map
authorPedro Alves <palves@redhat.com>
Sun, 11 Jun 2017 23:49:51 +0000 (00:49 +0100)
committerPedro Alves <palves@redhat.com>
Mon, 12 Jun 2017 16:06:25 +0000 (17:06 +0100)
"perf" shows the unordered_map::emplace call in write_hash_table a bit
high up on profiles.  Fix this using the find + insert idiom instead
of going straight to insert.

I tried doing the same to the other unordered_maps::emplace calls in
the file, but saw no performance improvement, so left them be.

With a '-g3 -O2' build of gdb, and:

  $ cat save-index.cmd
  set $i = 0
  while $i < 100
    save gdb-index .
    set $i = $i + 1
  end
  $ time ./gdb -data-directory=data-directory -nx --batch -q -x save-index.cmd  ./gdb.pristine

I get an improvement of ~7%:

  ~7.0s => ~6.5s (average of 5 runs).

gdb/ChangeLog:
2017-06-12  Pedro Alves  <palves@redhat.com>

* dwarf2read.c (write_hash_table): Check if key already exists
before emplacing.

gdb/ChangeLog
gdb/dwarf2read.c

index 4c8657cdc39fe1ea2d26a41c90a9b64b83236877..01b66a10d99486c0edd12d706251f3b8f0a87f9a 100644 (file)
@@ -1,3 +1,8 @@
+2017-06-12  Pedro Alves  <palves@redhat.com>
+
+       * dwarf2read.c (write_hash_table): Check if key already exists
+       before emplacing.
+
 2017-06-12  Pedro Alves  <palves@redhat.com>
 
        * dwarf2read.c (data_buf::append_space): Rename to...
index 63a591e5ebd5721507a61bbb239548f316664d5d..93fd2756a1f7bf8908e1b880030897c5f166adee 100644 (file)
@@ -23430,11 +23430,22 @@ write_hash_table (mapped_symtab *symtab, data_buf &output, data_buf &cpool)
        if (it == NULL)
          continue;
        gdb_assert (it->index_offset == 0);
-       const auto insertpair
-         = symbol_hash_table.emplace (it->cu_indices, cpool.size ());
-       it->index_offset = insertpair.first->second;
-       if (!insertpair.second)
-         continue;
+
+       /* Finding before inserting is faster than always trying to
+          insert, because inserting always allocates a node, does the
+          lookup, and then destroys the new node if another node
+          already had the same key.  C++17 try_emplace will avoid
+          this.  */
+       const auto found
+         = symbol_hash_table.find (it->cu_indices);
+       if (found != symbol_hash_table.end ())
+         {
+           it->index_offset = found->second;
+           continue;
+         }
+
+       symbol_hash_table.emplace (it->cu_indices, cpool.size ());
+       it->index_offset = cpool.size ();
        cpool.append_data (MAYBE_SWAP (it->cu_indices.size ()));
        for (const auto iter : it->cu_indices)
          cpool.append_data (MAYBE_SWAP (iter));