Daniel Jacobowitz wrote:
On Thu, Jan 17, 2008 at 09:46:16PM -0800, Pawel Piech wrote:
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.
Using a remote GDB server does not necessarily mean that GDB commands
go over the network. GDB runs on the same machine as Eclipse (not
always true, but 99% of the time). If GDB can respond to an MI
command without going over the network to gdbserver, it will always do
so.
There's still some benefit to caching in the frontend, because sending
commands over a local pipe to GDB/MI still takes time. But it won't
be as slow as reading target memory.
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).
Those extra fetches would be unfortunate. Why is this true? You
should only need to fetch things that are visible to the user.
Once the debugged program has run, GDB needs to ask gdbserver for
updated values; that's what -var-update does.
I think what Marc meant was that after a resume/suspend, even if
-var-update indicates that a given variable hasn't changed the IDE will
need to retrieve it's value because of the ambiguity of the value
formats. However, only variables which are visible on the screen will
be requested by the UI from the service, so if a variable wasn't
visible, a -var-update would never be called for it anyway.
Cheers,
Pawel
|
