From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25813 invoked by alias); 13 May 2002 04:31:48 -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 25733 invoked from network); 13 May 2002 04:31:47 -0000 Received: from unknown (HELO localhost.redhat.com) (24.112.240.27) by sources.redhat.com with SMTP; 13 May 2002 04:31:47 -0000 Received: from cygnus.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id DCA663E08; Mon, 13 May 2002 00:31:09 -0400 (EDT) Message-ID: <3CDF418D.9080504@cygnus.com> Date: Sun, 12 May 2002 21:31:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0rc1) Gecko/20020429 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Jacobowitz Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] Type cleanups References: <20020513003359.GA11672@nevyn.them.org> <3CDF3081.1020900@cygnus.com> <20020513034024.GA27096@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-05/txt/msg00443.txt.bz2 > 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. 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 :-) enjoy, Andrew