| Re: [dsdp-dd-dev] FW: RE: -var-update using formatted value |
|
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 [...] |