From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14941 invoked by alias); 27 Sep 2002 18:23:28 -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 14928 invoked from network); 27 Sep 2002 18:23:26 -0000 Received: from unknown (HELO zenia.red-bean.com) (66.244.67.22) by sources.redhat.com with SMTP; 27 Sep 2002 18:23:26 -0000 Received: (from jimb@localhost) by zenia.red-bean.com (8.11.6/8.11.6) id g8RI7wc27915; Fri, 27 Sep 2002 13:07:58 -0500 To: Daniel Jacobowitz CC: gdb@sources.redhat.com Subject: Re: suggestion for dictionary representation References: <20020925125436.GA10407@nevyn.them.org> From: Jim Blandy In-Reply-To: <20020925125436.GA10407@nevyn.them.org> User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2.90 Date: Fri, 27 Sep 2002 11:23:00 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-09/txt/msg00483.txt.bz2 Daniel Jacobowitz writes: > On Tue, Sep 24, 2002 at 10:46:02PM -0500, Jim Blandy wrote: > > > > Daniel Berlin writes: > > > > > On Tue, 24 Sep 2002, Jim Blandy wrote: > > > > > > > > > > > > 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. > > > > > > Um, I have these statistics, but I need to know *exactly* what you want to > > > know to be able to give them to you. > > > > On large C++ programs, how much of a difference would it make if we > > used `struct symbol' objects (52 bytes long) to represent data members > > and member functions, instead of `struct field' and `struct fn_field' > > objects (both 16 bytes long)? > > I'm not sure this is the way to go - we could have a dictionary of > something other than struct symbol, probably. Well, for fields, I think you're right. The field list is intrinsically an ordered thing; a dictionary is not. But not for methods, either? Wouldn't it simplify overload set computation to have methods and ordinary functions represented using the same structure?