Helping with KDE4 (valgrind)

[David Faure]

On Tuesday 09 May 2006 18:18, İsmail Dönmez wrote:
> Dirk Mueller wrote On 09-05-2006 10:37:
> > On Tuesday, 9. May 2006 02:33, Julian Seward wrote:
> >
> >> Hmm, I'm not in much of a position to advise on what's a good
> >> serialising/deserialising arrangement.  I would say that minimising
> >> the total number of bytes passed will probably help.  Why don't you
> >> just pass binary structs around?   Converting to/from ASCII takes
> >> time.
> >
> > Well, its ASCII data from the start with ;) Anyway, reading proc filesystems
> > is very slow, and every access has to be reduced. However, I don't think that
> > this is the limiting factor, and the preliminary numbers of Julian pointed
> > out that when you spend 70% of your time in processEvents, then the data
> > marshalling is not your issue.
> 
> I remember seeing processEvents() in top of konversation cachegrind
> output, any usual suspects to check for this ?
> There is no direct kapp->processEvents() call in the code AFAIK.

GUI applications spend most of their time processing events (coming from
the user or from the windowing system), this should hardly be a surprise.

In fact except for the code in main(), all the code in your application is called
by processEvents, more or less indirectly!

So it's quite normal that it's at the top of the cumulated costs list of methods,
there is nothing wrong there. A GUI app is either idle (waiting for events)
or processing those events.

To profile a GUI app you should rather look at the highlevel methods that actually
do stuff, like a load() method, or a method that calculates stuff... in case of
synchronous code like that it's easy; in case of async stuff (like receiving data
from the network) it's bit more difficult since the processing is split into slices;
but of course the aggregated cost will still show up if it's too high.

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).