Re: libGDB architecture

[James Ingham <jingham@leda.cygnus.com>]

Andrew Cagney <ac131313@cygnus.com> 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" <msnyder@cygnus.com>
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 <ac131313@cygnus.com>
>   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.