From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 49901 invoked by alias); 2 Oct 2019 17:18:39 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 49860 invoked by uid 89); 2 Oct 2019 17:18:38 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-8.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy= X-HELO: gateway36.websitewelcome.com Received: from gateway36.websitewelcome.com (HELO gateway36.websitewelcome.com) (192.185.185.36) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 02 Oct 2019 17:18:36 +0000 Received: from cm17.websitewelcome.com (cm17.websitewelcome.com [100.42.49.20]) by gateway36.websitewelcome.com (Postfix) with ESMTP id 6CDF240271CA5 for ; Wed, 2 Oct 2019 11:25:08 -0500 (CDT) Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with SMTP id FiGniIczIPUvSFiGniwWRI; Wed, 02 Oct 2019 12:18:33 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tromey.com; s=default; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=42B5GyDjlyn21LkNglvUp6fhkWJ663aU2rlvhmr9d08=; b=Xn9EKrEr8PjhooDuCzG9Sc4JQC tpZAs/aQuUd0l3OXaKghtR5Rt4ANYL6D4DbZhAcp7e4hWa1V+yLZ9HHml5bfqkQktm5eTIKrbHxI2 NO1NT6j97LngNgBHhz7RpDxT+; Received: from 75-166-72-156.hlrn.qwest.net ([75.166.72.156]:49306 helo=murgatroyd) by box5379.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1iFiGn-001p8j-94; Wed, 02 Oct 2019 11:18:33 -0600 From: Tom Tromey To: "Christian Biesinger via gdb-patches" Cc: Christian Biesinger Subject: Re: [PATCH] Don't use the mutex for each symbol_set_names call References: <874l0tc1gl.fsf@tromey.com> <20190930165543.68106-1-cbiesinger@google.com> Date: Wed, 02 Oct 2019 17:18:00 -0000 In-Reply-To: <20190930165543.68106-1-cbiesinger@google.com> (Christian Biesinger via gdb-patches's message of "Mon, 30 Sep 2019 11:55:43 -0500") Message-ID: <87r23vxdzs.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2019-10/txt/msg00072.txt.bz2 >>>>> "Christian" == Christian Biesinger via gdb-patches writes: Christian> It speeds up "attach to Chrome's content_shell binary" from 44 sec -> 30 Christian> sec (32%) (compared to GDB trunk), or from 37 sec compared to this Christian> patchset before this patch. Nice. Christian> + [&] (minimal_symbol *first, minimal_symbol* last) { Christian> + std::lock_guard guard (demangled_mutex); Christian> + for (; first < last; ++first) { Christian> + symbol_set_names (first, first->name, Christian> + strlen (first->name), 0, Christian> + m_objfile->per_bfd); Christian> + } Christian> + }); IIUC the idea is to separate the demangling from updating the demangled_names_hash. A couple of thoughts on that... Christian> + *slot Christian> + = ((struct demangled_name_entry *) Christian> + obstack_alloc (&per_bfd->storage_obstack, Christian> + offsetof (struct demangled_name_entry, demangled) Christian> + + len + demangled_len + 2)); Christian> + mangled_ptr = &((*slot)->demangled[demangled_len + 1]); Christian> + strcpy (mangled_ptr, linkage_name_copy); Christian> + (*slot)->mangled = mangled_ptr; There's no deep reason that these things have to be stored on the per-BFD obstack -- and requiring this means an extra copy. Instead we could change the hash table to use ordinary heap allocation, and I think this would be more efficient when demangling in worker threads, because we could just reuse the existing allocation. Also, it seems fine to serialize the calls to symbol_set_names. There's no need for a lock at all, then. One idea I had was to parallelize build_minimal_symbol_hash_tables as well: when possible, have it run two threads, and create the hash tables in parallel. Adding a third thread here to update the demangled_names_hash might help too? Maybe this approach would eliminate the need for your "Compute msymbol hash codes in parallel" patch ... the issue there being that it makes the minsyms larger. (Another way to handle that would be to keep the hashes in a local array of some kind that is discarded once the hash tables are updated.) Tom