From mboxrd@z Thu Jan 1 00:00:00 1970 From: James Ingham To: gdb@sourceware.cygnus.com Subject: Re: libGDB architecture Date: Sat, 27 Nov 1999 18:50:00 -0000 Message-id: References: <199909162200.PAA21351@hercules.cup.hp.com> <37E6F077.F75C8BE8@cygnus.com> X-SW-Source: 1999-q4/msg00338.html Andrew Cagney writes: > > I think a better (safer, more likely to succeed) approach would be to, > in parallel with the introduction of a robust interface, start > investigating what have been identified as other (likely) hot spots. > Interestingly, many of the below are actually independent of the libGDB > interface: > I agree with Andrew here. We can get a lot of benefit just breaking down some of the atomic operations in the GDB interface into useable bits. We have already done this with the variable interface (see gdbtk-variable.c) Another example where you need to do this is in the backtrace command. For most GUI purposes, you really don't want an undifferentiated list of 100 stack elements with all their arguments, names, types... Parsing and displaying this was very slow. You really want one command that just gives you the list of functions on the stack. Then a way to get the args (preferrably already list-ified) for each level. That way you can do intelligent things like only fetch what fits in the current window, and get the others on scrolling or whatever... This is just one other example. There are other places where providing a more discrete interface into gdb would be a big benefit, and probably reduce most of the need to get your hands on the actual data in gdb. I am still worried about parsing very large arrays, etc, however. For this to be fast, you probably will have to somehow get the data directly... > Your too trusting :-) > > Andrew > > PS: See Tcl_IncrRefCount and Tcl_DecrRefCount There are actually two places where Tcl does preservation of data. One is in the Object system, which uses the calls Andrew sites above, and one is for clients that want to hold data over a call that may potentially free it - see Tcl_Preserve and Tcl_EventuallyFree. Jim -- ++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++ Jim Ingham jingham@cygnus.com Cygnus Solutions Inc. >From msnyder@cygnus.com Sat Nov 27 18:50:00 1999 From: "Michael Snyder" To: gdb@sourceware.cygnus.com Subject: Re: QUIT as a function? Date: Sat, 27 Nov 1999 18:50:00 -0000 Message-id: <7svn12$576$1@cronkite.cygnus.com> References: <199909171842.LAA10740@andros.cygnus.com> X-SW-Source: 1999-q4/msg00336.html Content-length: 594 Stan Shebs wrote in message <199909171842.LAA10740@andros.cygnus.com>... > > From: Andrew Cagney > Date: Fri, 17 Sep 1999 15:14:42 +1000 > > Is there any reason for not converting QUIT into a function? > >Yes, QUIT appears in the inner loops of the symbol readers, which >are known to be compute-bound and some of the most time-critical >code in all GDB. True, but there's so much going on in those symbol readers (including file accesses) that I can't believe one function call, even in the innermost loop, would make a measurable difference.