Re: [cdt-dev] Multicore Visualizer on 576 cores

[Xavier Raynaud <xavier.raynaud@xxxxxxxxx>]

Hi,

It helps:
By using cache + override some methods in IProcesses service, I dramatically decrease the number of mi commands sent to gdb.
Therefore, performance is now OK.

Many thanks,

Xavier

----- Mail original -----
De: "Marc Khouzam" <marc.khouzam@xxxxxxxxxxxx>
À: "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
Envoyé: Vendredi 27 Juin 2014 16:34:17
Objet: Re: [cdt-dev] Multicore Visualizer on 576 cores

[...]
> > If the visualizer uses the DSF services, the caching mechanism should
> > kick in and there should be no need to go back to GDB for the
> > information that was already fetched.
> 
> I've seen that. I started to use the caching mechanism, and I gain a few time.
> Note: I didn't found any documentation about DSF caching mechanism. Is it
> documented somewhere ?

Not that I know of.  Normally we use the class CommandCache.java to cache
GDB commands and answers, to avoid having to send them again.  That
cache has traces you can enable under o.e.cdt.dsf/debugCache to see
when the cache is hit.

The idea is that when you send a GDB command through the cache
and that command was sent before, the cache will immediately answer
with the recorded result; if the command is not in the cache, it will
send it to the commandControl service to send to GDB.
That cache must also be cleared and appropriate events, depending
on the situation.

You can look at how it is used in our different existing services. 

In some cases, you may choose to implement your own caching
structure if the CommandCache does not suit your needs.

I hope this helps.

Marc