Re: [cdt-dev] Variables View / Registers View architecture.

["Mikhail Khodjaiants" <mikhailk@xxxxxxx>]

Hi Bala,

I am not sure I understand the question. The view (to be more accurate, the 
view's content provider) triggers the commands you mentioned. Each command 
is a result of a method invocation in CVariable, but all methods are called 
from the view contend provider.

Mikhail
----- Original Message ----- 
From: "Balasubramaniyan K" <balask@xxxxxxxxxxxx>
To: "'CDT General developers list.'" <cdt-dev@xxxxxxxxxxx>
Sent: Friday, June 24, 2005 6:00 AM
Subject: RE: [cdt-dev] Variables View / Registers View architecture.


> Hi Mikhail,
>
>    My question is about not rendering f the debugger view.
>
>    I would like to know the root class which is issuing the command in
> sequence. I would like to change the sequence of the
> commands as follows :
>
> whatis $fr68
> whatis $fr69
> whatis $fr70
> ...
>
> -var-create - * $fr68
> -var-create - * $fr69
> -var-create - * $fr70
> ....
>
> var-evaluate-expression var36
> var-evaluate-expression var37
> var-evaluate-expression var38
> ...
>
> Thanks,
> Bala
>
> > -----Original Message-----
> > From: cdt-dev-bounces@xxxxxxxxxxx
> > [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Mikhail Khodjaiants
> > Sent: Wednesday, June 22, 2005 11:28 PM
> > To: CDT General developers list.
> > Subject: Re: [cdt-dev] Variables View / Registers View architecture.
> >
> > Bala,
> >
> > The CDT provides only the implementation of the Eclipse Debug
> > Platform API.
> > The rendering of a debugger view is done by the view itself.
> > To find out how it wprks look at the VariablesView,
> > VariablesViewer, RemoteTreeContentProvider,
> > RemoteTreeContentManager etc. classes.
> >
> > Mikhail
> > ----- Original Message -----
> > From: "Balasubramaniyan K" <balask@xxxxxxxxxxxx>
> > To: <jdt-dev@xxxxxxxxxxx>; <cdt-dev@xxxxxxxxxxx>
> > Sent: Wednesday, June 22, 2005 10:40 AM
> > Subject: [cdt-dev] Variables View / Registers View architecture.
> >
> >
> > >
> > > Hi,
> > >
> > >
> > > Before I explain my understanding about the Architecture of
> > Variables
> > > View or Registers View, let me try to explain my actual
> > > problem
> > >
> > > I am trying to do a remote debug operation from Eclipse /
> > CDT. Though I
> > > am succesful, yet there is a considerable performance delay
> > > in Variables & Registers View.
> > > After conducting few experiments, we have found out that performance
> > > delay is due to the network latency. In other words, Eclipse
> > > transmits a command & waits until GDB sends
> > > a response & vice versa. Due to this, GDB at the remote end
> > is idle most
> > > of the time. For every request & response, the round trip
> > > time is 203 milliseconds & for 70 variables in context,
> > > the variables view takes 10 seconds to come up.  The
> > solution which we
> > > could think of this, we could remove the wait state of the
> > > transmitter ie., Tx keeps pumping commands to the GDB so that GDB is
> > > always in state of sending response. By this , we could remove
> > > 203 milliseconds for each command.  This is an idea. Is
> > there any better
> > > solution ?
> > >
> > > Now coming to my understanding,
> > >
> > > For every variables for a context , there are three
> > operations that are
> > > being carried viz., whatis, -var-create &
> > > -var-evaluate-expression. Through the Stack-list-locals
> > commands, all
> > > the local variables in the context are obtained & these are
> > > dumped to the RegisterDescriptor[] or VariableDescriptor[] data
> > > structure as applicable. Then there is a ***Job**** that is getting
> > > created which runs all the three commands on each & every
> > variable. I
> > > have *starred*  at the code for a while now .Unfortunately, I
> > > am  not able to find the piece that connects these
> > ***Job*** & how they
> > > execute these three commands for every variable in the
> > > context & who is starting these jobs.
> > >
> > > Any help would be greatly appreciated  ?
> > >
> > >
> > > Warm Regards
> > > Bala
> > >
> > >
> > > _______________________________________________
> > > cdt-dev mailing list
> > > cdt-dev@xxxxxxxxxxx
> > > https://dev.eclipse.org/mailman/listinfo/cdt-dev
> >
> > _______________________________________________
> > cdt-dev mailing list
> > cdt-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/cdt-dev
>
>
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev