Hi Marc,
It seems that the question of what and how much to cache in the IDE
comes up periodically. In the past, a rule of thumb that we used is
that if a given request may go over the network, it's probably worth
caching. For GDB, i think using a remote GDB server would involve
executing GDB commands over the network, although I honestly can't tell
how common is that use case.
We used this rule of thumb because the UI components using the service
may be rather dumb and may request the same data over and over while
painting in the UI. That said, we are also currently implementing more
caching at the UI level and improving the efficiency of UI in general,
which should reduce the importance of the caching in the services. So
I think at this point the question whether to cache _expression_ commands
should depends most on what is most convenient to the implementation
The _expression_ command caching is already in place and it's pretty well
tested. However from the discussion on the GDB mailing list it seems
that the GDB _expression_ protocol is so convoluted that keeping a
client-side cache consistent is problematic.
>From the two caches you list below, the first cache (meta command
cache) seems more important to me. I doubt whether the second cache
has that much performance impact since it's relevant only after each
resume command.
Cheers,
-Pawel
Marc Khouzam wrote:
Hi,
I think point 1 in the below email is good one.
I had started blurring the concept of backend and GDB, but in our DSF setup,
it is true that GDB will be running on the front-end, right?
With the GDB-Server on the backend. Therefore, whatever is cached by GDB, needs not
be cached by our GDB/MI implementation. Is that correct?
So now, I wonder about the usefulness of two of our caches of the ExpressionService.
1- the special meta command cache may not be necessary, since GDB should already be
caching those values. Although this cache does work and can be a good example for
other debuggers that don't cache as GDB does.
2- the format-value cache which could simply rely on the internal GDB cache
as mentioned in the email below. Since this cache needs a workaround to properly
work with the current implementation of var-update, it would be easier to get rid
of it. But that means that after every 'Resume', each value, even if not changed
will need to be fetched from GDB (but not from GDB-server).
Any opinions?
Thanks
Marc
-----Original Message-----
From: gdb-owner@xxxxxxxxxxxxxx [mailto:gdb-owner@xxxxxxxxxxxxxx]On
Behalf Of Vladimir Prus
Sent: Thursday, January 17, 2008 1:02 PM
To: gdb@xxxxxxxxxxxxxxxxxx
Subject: RE: -var-update using formatted value
[...]
If I have a varObject displaying 0x1 in hex and then I want to show the
value in binary, I will need to go to the target.
No. GDB keeps the raw value inside the variable object, and changing
format only changed the way gdb converts that raw value into string.
For embedded systems, we want to
reduce the communication with GDB to a minimum, because GDB itself is
running on a potentially slow processor, with a small bandwidth connection
to the front-end. That is why I am trying to cache all values.
I have two observations:
1. Generally, it's best to run gdb on the same system where you run IDE,
and have it talk to remote stub on the target system.
2. Even if you run gdb on target, changing varobj format is very fast,
so I'm not sure caching formats is an important thing to do. Did you
actually run into a case where the performance of changing format is
unacceptable?
- Volodya
_______________________________________________
dsdp-dd-dev mailing list
dsdp-dd-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-dd-dev
|