From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11634 invoked by alias); 13 May 2002 18:46:55 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 11627 invoked from network); 13 May 2002 18:46:54 -0000 Received: from unknown (HELO nevyn.them.org) (128.2.145.6) by sources.redhat.com with SMTP; 13 May 2002 18:46:54 -0000 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 177KqR-0004MI-00; Mon, 13 May 2002 14:46:51 -0400 Date: Mon, 13 May 2002 11:46:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] Type cleanups Message-ID: <20020513184651.GA16618@nevyn.them.org> Mail-Followup-To: Andrew Cagney , gdb-patches@sources.redhat.com References: <20020513003359.GA11672@nevyn.them.org> <3CDF3081.1020900@cygnus.com> <20020513034024.GA27096@nevyn.them.org> <3CDF418D.9080504@cygnus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3CDF418D.9080504@cygnus.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2002-05/txt/msg00481.txt.bz2 On Mon, May 13, 2002 at 12:31:09AM -0400, Andrew Cagney wrote: > >Does this mean that ``struct type *'' is becoming opaque? Looking at > >>the next patch, no, sigh. > > > > > >No. It's accessed so frequently that switching from macros to accessor > >functions would be a ridiculous performance hit, I think. > > The last time this came up, the consensus was that a macro should be > converted to a function, even when it resulted in a performance loss > (things were a bit vague on how much). The debate was about STREQ which > is in the critical path for symbol table reading and the like. STREQ is an entirely different problem, IMHO. For one thing, compilers do a pretty good job of strcmp on their own; for another, the function call is heavily optimized. > Anyway, I tend to look at it more pragmatically. Is my (your, and other > developers) time best spent chasing after people that forget to or > wrongly use the accessor macro, or, on fixing real problems. Given that > I'm struggling to show a performance gain from a frame based register > cache, and no one has noticed me adding another assertion to every > gdbarch accessor function, I don't expect changing the above to opaque > to be a significant problem :-) I think you may be underestimating the frequency of some of the TYPE accessors... but if I get a chance, I'll benchmark it. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer