From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19917 invoked by alias); 4 Apr 2002 17:47:13 -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 19910 invoked from network); 4 Apr 2002 17:47:11 -0000 Received: from unknown (HELO localhost.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 4 Apr 2002 17:47:11 -0000 Received: from cygnus.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 6B6473E78; Thu, 4 Apr 2002 12:47:12 -0500 (EST) Message-ID: <3CAC91A0.3000702@cygnus.com> Date: Thu, 04 Apr 2002 09:47:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:0.9.9) Gecko/20020328 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Jacobowitz Cc: gdb@sources.redhat.com Subject: Re: gdb/457: GDB runs slow (internal doco needed) (FAQ) References: <20020404165802.6629.qmail@sources.redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-04/txt/msg00058.txt.bz2 [mailing list changed] >> Related to the above. Being able to identify just the information that changed so that GUI refresh operations are limited to areas that need an update. See varobj.[ch]. > > > If profiling GDB to improve performance it is important to look > > beyond the raw numbers (some one line pid/tid functions come up as > > ``hot spots'') and more at the overall picture (the thread_info > > object should be used). Replacing apparently hot functions with > > macros isn't an option. > > If the thread_info object is used, we're still going to have all the > little accessor functions. Why the categorical objection to macros? > Especially in places that they would especially benefit compiler > performance, like one-line accessor macros? And even more so since GDB > will soon support better macro debugging... I'll be ok with macro's when you can step into them, print their local (macro) variables, ensure (using compiler warnings) that the user can't grub a round directly in the object the macro is wrapping, not have any side effects, not have pass by name problems, .... Even static functions in headers are less evil than macros. As for accessor functions and an opaque type - I see only benefits. It forces discussion when adding new accessor methods or techniques; it allows the internals to be re-written; it stops people grubbing around where they shouldn't; and it removes the need for constant vigalnce by the maintainer - checking that someone isn't bit rotting the code by adding a grub. > ptid_get_pid () isn't going away, and by "coming up as ``hot spots''" I > remember something like 10% _wall clock time_ in these little functions > on some test cases. Look at the STREQ() hack. A micro optomization that tried to hide a more global (bad algorithms) problem. I'm pretty sure that there is the same situtation here - there is a problem with how GDB represents this info internally. If the general case really is: thread (with a frame) N:M light-weight-process (with a regcace) Then perhaps GDB's internal data structures should reflect this - an abstract ``struct thread_info'' with a frame. A more concrete ``struct lwp_info'' with hard registers. Andrew