From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17473 invoked by alias); 16 Dec 2018 17:01:34 -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 17458 invoked by uid 89); 16 Dec 2018 17:01:34 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-0.4 required=5.0 tests=BAYES_00,KAM_STOCKGEN,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS autolearn=no version=3.3.2 spammy=seriously, wondered, concerned, noticeable X-HELO: gateway31.websitewelcome.com Received: from gateway31.websitewelcome.com (HELO gateway31.websitewelcome.com) (192.185.143.4) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 16 Dec 2018 17:01:32 +0000 Received: from cm12.websitewelcome.com (cm12.websitewelcome.com [100.42.49.8]) by gateway31.websitewelcome.com (Postfix) with ESMTP id BDD594B1C4D for ; Sun, 16 Dec 2018 11:01:30 -0600 (CST) Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with SMTP id YZnGga7ZliQerYZnGggBwi; Sun, 16 Dec 2018 11:01:30 -0600 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=KXESQWOZQFQsrxwU7kC2JRZIqeeln3j1atFPKuqDX3w=; b=DjeGWspEVIPNzYD71nRC5AkvL7 FIGzu/mGnAsoJFon8i9C7yAX9kuHI+GQd81i/gx2vNk6dsr31cw/V6/z3GpKLnTSGRelhsLKymjoY dokvLVSzjKQazS2e2k2iiyZmL; Received: from 75-166-72-210.hlrn.qwest.net ([75.166.72.210]:46412 helo=bapiya) by box5379.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1gYZnG-000QcC-Gb; Sun, 16 Dec 2018 11:01:30 -0600 From: Tom Tromey To: Keith Seitz Cc: gdb-patches@sourceware.org Subject: Re: [PATCH 1/5] gdb/23712: Introduce multidictionary's References: <20181109022847.32049-1-keiths@redhat.com> Date: Sun, 16 Dec 2018 17:01:00 -0000 In-Reply-To: <20181109022847.32049-1-keiths@redhat.com> (Keith Seitz's message of "Thu, 8 Nov 2018 18:28:43 -0800") Message-ID: <87lg4p4d92.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1.90 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2018-12/txt/msg00187.txt.bz2 >>>>> "Keith" == Keith Seitz writes: Keith> gdb/23712 is a new manifestation of the now-infamous (at least to me) Keith> symtab/23010 assertion failure (DICT_LANGUAGE == SYMBOL_LANGAUGE). Keith> I've done exhaustive performance testing with this approach, and I've Keith> attempted to minimize the overhead for the (overwhelmingly) most common Keith> one-language scenario. I'm not super concerned about this. I wonder a bit more about the memory overhead, though. Keith> [I've tested only GDB and firefox with -readnow.] In general my view is that -readnow performance just isn't important, since no users should ever do that, and CU expansion is rarely noticeable anyhow. (And, if CU expansion performance is a problem, I'll note there are some relatively simple ways to greatly speed it up that we have never seriously pursued.) Keith> +struct multidictionary Keith> +{ Keith> + /* An array of dictionaries, one per language. All dictionaries Keith> + must be of the same type. This should be free'd for expandable Keith> + dictionary types. */ Keith> + struct dictionary **dictionaries; Keith> + Keith> + /* The number of language dictionaries currently allocated. Keith> + Only used for expandable dictionaries. */ Keith> + unsigned short n_allocated_dictionaries; Keith> +}; I think this is the main possibly contentious bit of this series. I wondered when reading this series why it isn't possible to just put symbols of multiple languages into a single hash table. That would seem to make the series as a whole much simpler: no mass renaming, no need to store multiple dictionaries in a block, etc. Maybe one problem is that when searching you may only have the searched-for symbol name; so you'd have to maybe keep a bitset of all the languages in a dictionary and then do multiple hash lookups? But still that seems better. Don't rush off to change anything yet! I'd rather we discuss it before asking for more work. Also I'd appreciate opinions from anybody else listening. thanks, Tom