Helping with KDE4 (valgrind)

John Tapsell johnflux at
Mon May 8 19:50:22 BST 2006

It's about 20kb of information every couple of seconds in total.
The default refresh is every 2 seconds.
I would rather not change ksysguardd if it turns out to be fast
enough, since I would like to keep compatibility with the kde3.5
version of ksysguardd.

On 5/8/06, Guillaume Laurent <glaurent at> wrote:
> On Monday 08 May 2006 19:54, John Tapsell wrote:
> > Hi Julian,
> >
> >   This is great timing!  ksysguard (the process viewer thing)
> > communicates to ksysguardd.  I would love to know if communicating via
> > pipes (serialising/sending/recieving/deserialising) etc is slow, or
> > whether I should code some kind of faster track for the common case of
> > watching the local machine.
> Depends on what you're sending. Pipes are very fast (this from reading a
> design doc on jackit, where the author was explaining the various IPC means
> available, pipes, sockets, etc...), and I doubt that ksysguard requires a
> voluminous set of data.
> However, if ksysguardd is basically maintaining a fixed-size data struct
> describing the state of the machine and sending that, then you can do
> something like what we do with RG to communicate between the GUI and the
> sequencer process : both processes mmap() a file containing that struct, and
> you get instant communication between both.
> The downside is that it forces you to implement a wholly different
> communication scheme for the local case. That said, is ksysguard really
> useful for the local case ? There are plenty of other much lighter
> alternatives to monitor the state of your machine.
> --
> Guillaume.

More information about the kde-core-devel mailing list