From patchwork Mon Jun 12 16:14:09 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Pedro Alves X-Patchwork-Id: 20958 Received: (qmail 89987 invoked by alias); 12 Jun 2017 16:14:14 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 88021 invoked by uid 89); 12 Jun 2017 16:14:12 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-25.9 required=5.0 tests=BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, KAM_LAZY_DOMAIN_SECURITY, SPF_HELO_PASS, T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy= X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 12 Jun 2017 16:14:11 +0000 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id DCA0565743 for ; Mon, 12 Jun 2017 16:14:14 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com DCA0565743 Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=palves@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com DCA0565743 Received: from cascais.lan (ovpn04.gateway.prod.ext.ams2.redhat.com [10.39.146.4]) by smtp.corp.redhat.com (Postfix) with ESMTP id 6A6AE80F6F for ; Mon, 12 Jun 2017 16:14:14 +0000 (UTC) From: Pedro Alves To: gdb-patches@sourceware.org Subject: [PATCH 4/6] .gdb_index prod perf regression: find before insert in unordered_map Date: Mon, 12 Jun 2017 17:14:09 +0100 Message-Id: <1497284051-13795-4-git-send-email-palves@redhat.com> In-Reply-To: <1497284051-13795-1-git-send-email-palves@redhat.com> References: <1497284051-13795-1-git-send-email-palves@redhat.com> In-Reply-To: <8efc0742-1014-4fe0-6948-f40a9c5c4975@redhat.com> References: <8efc0742-1014-4fe0-6948-f40a9c5c4975@redhat.com> "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 * dwarf2read.c (write_hash_table): Check if key already exists before emplacing. --- gdb/ChangeLog | 5 +++++ gdb/dwarf2read.c | 21 ++++++++++++++++----- 2 files changed, 21 insertions(+), 5 deletions(-) diff --git a/gdb/ChangeLog b/gdb/ChangeLog index 4c8657c..01b66a1 100644 --- a/gdb/ChangeLog +++ b/gdb/ChangeLog @@ -1,5 +1,10 @@ 2017-06-12 Pedro Alves + * dwarf2read.c (write_hash_table): Check if key already exists + before emplacing. + +2017-06-12 Pedro Alves + * dwarf2read.c (data_buf::append_space): Rename to... (data_buf::grow): ... this, and make private. Adjust all callers. (data_buf::append_uint): New method. diff --git a/gdb/dwarf2read.c b/gdb/dwarf2read.c index 63a591e..93fd275 100644 --- a/gdb/dwarf2read.c +++ b/gdb/dwarf2read.c @@ -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));