From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4429 invoked by alias); 24 Nov 2010 18:53:00 -0000 Received: (qmail 4418 invoked by uid 22791); 24 Nov 2010 18:52:58 -0000 X-SWARE-Spam-Status: No, hits=-5.4 required=5.0 tests=AWL,BAYES_00,KAM_STOCKGEN,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,TW_BJ,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 24 Nov 2010 18:52:53 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id oAOIqUBE018184 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 24 Nov 2010 13:52:30 -0500 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id oAOIqTVX031074; Wed, 24 Nov 2010 13:52:29 -0500 Received: from opsy.redhat.com (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id oAOIqTOe029676; Wed, 24 Nov 2010 13:52:29 -0500 Received: by opsy.redhat.com (Postfix, from userid 500) id C40D2C884CC; Wed, 24 Nov 2010 11:52:28 -0700 (MST) From: Tom Tromey To: Jan Kratochvil Cc: Joel Brobecker , gdb-patches@sourceware.org Subject: Re: [patch 2/2] iFort compat.: case insensitive symbols (PR 11313) References: <20101108183133.GE2933@adacore.com> <20101122035334.GA9229@host0.dyn.jankratochvil.net> <20101122185432.GT2634@adacore.com> <20101122191905.GA20976@host0.dyn.jankratochvil.net> <20101122193041.GU2634@adacore.com> <20101122194336.GA21855@host0.dyn.jankratochvil.net> Date: Wed, 24 Nov 2010 18:53:00 -0000 In-Reply-To: <20101122194336.GA21855@host0.dyn.jankratochvil.net> (Jan Kratochvil's message of "Mon, 22 Nov 2010 20:43:36 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 X-SW-Source: 2010-11/txt/msg00400.txt.bz2 >>>>> "Jan" == Jan Kratochvil writes: Jan> There is more an issue MINIMAL_SYMBOL_HASH_SIZE is constant: Jan> #define MINIMAL_SYMBOL_HASH_SIZE 2039 Jan> Some objfiles have many symbols: Jan> libwebkit.so.debug: 54980 symbols Jan> /MINIMAL_SYMBOL_HASH_SIZE = 27 Jan> log2(54980)=16 I looked at this a long time ago, when I was trying to reduce memory use. My recollection is that our hashing here is pretty bad. I seem to remember a case where we had some empty hash buckets and some buckets with 20 symbols. Jan> In such case in fact the whole hash table makes no sense and it is even Jan> cheaper to just do binary search on objfile->msymbols which is already Jan> qsort-ed and be done with it. msymbols is sorted by address first. Note that changing this area is trickier than it seems due to the mst_solib_trampoline handling in lookup_minimal_symbol (maybe obvious, but it took me a while to realize it...). Jan> Still a hash table should be faster than a binary search but the Jan> hash table size would need to be adaptable. I implemented this :-). It slowed down startup, so it didn't go in. See the archives around 2008-08-27. Given your other comments this hit may not be relevant. I still have the patch if you are interested. Jan> But rather than optimizations of this which reduce just the CPU Jan> load which was in my measurements 2% during GDB startup (due to its Jan> waiting on disk). We could for example rather delay Jan> searching+loading any objfiles' symbols we do not need which would Jan> do another major GDB startup time reduction like .gdb_index did. Yeah, this would be interesting to see. I think find_main_filename may make this difficult, but maybe it would work ok for the attach case. This sort of reading could maybe be done in a background thread. Also, I wonder why we read minsyms from separate debuginfo files. Is that ever needed? Tom