From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22649 invoked by alias); 24 Sep 2002 16:49:14 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 22630 invoked from network); 24 Sep 2002 16:49:12 -0000 Received: from unknown (HELO jackfruit.Stanford.EDU) (171.64.38.136) by sources.redhat.com with SMTP; 24 Sep 2002 16:49:12 -0000 Received: (from carlton@localhost) by jackfruit.Stanford.EDU (8.11.6/8.11.6) id g8OGn5o08162; Tue, 24 Sep 2002 09:49:05 -0700 X-Authentication-Warning: jackfruit.Stanford.EDU: carlton set sender to carlton@math.stanford.edu using -f To: Jim Blandy Cc: gdb@sources.redhat.com Subject: Re: suggestion for dictionary representation References: <200209240635.g8O6ZUC23979@zenia.red-bean.com> From: David Carlton Date: Tue, 24 Sep 2002 09:49:00 -0000 In-Reply-To: <200209240635.g8O6ZUC23979@zenia.red-bean.com> Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-09/txt/msg00380.txt.bz2 On Tue, 24 Sep 2002 01:35:30 -0500, Jim Blandy said: >> Also, for what it's worth, I'm still not ready to completely give up >> on representing members of classes via a dictionary; that would >> provide another place where a linear dictionary environment could be >> useful. > I agree, but it's worth noting that `struct symbol' is 52 bytes long > on a Pentium, whereas `struct field' and `struct fn_field' are 16 > bytes long. > Not that that necessarily matters. We know GDB does have memory > consumption problems, but I have never seen those problems really > analyzed. Right. It wouldn't be something to do lightly, but on the other hand it's not something to rule out of hand without appropriate profiling. One possible alternative would be to add a dictionary to each compound data structure (or, as you suggest, only to certain compound data structures) that knows how to test whether or not a name is in that structure, but that always returns the same symbol for a match. That would let us get rid of the is_a_field_of_this argument to lookup_symbol; C++ code could then handle that symbol as a possible return value and would have enough information to do the right thing, whereas non-C++ code could ignore the possibility (or gdb_assert that it was never returned), and it would work automatically with a correct C++ name lookup algorithm. It would, of course, still increase GDB's memory usage, but it wouldn't increase it for every single field. David Carlton carlton@math.stanford.edu