Helping with KDE4 (valgrind)

[Julian Seward]

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.

J

On Tuesday 09 May 2006 01:01, John Tapsell wrote:
> Thanks.  I'll run that against trunk (I'm not really interested in
> 3.{4,5}  at the moment.  But I got the idea of what to do.
>
> It's about 200kb of data, but it's got to be serialised and
> deserialised.  (It's just a plain text dump.  Values are seperated
> with tabs).
>
> For example, if you do:  "ps?"  to ksysguardd, it replies:
> ksysguard> pid ppid name
>
> then you say "ps"  to it:
>
> 1 0 init
> 123 1 ksysguardd
>
> etc.  Of course with more fields and more rows, but that's it.  Would
> that be particularly expensive?
>
> On 5/8/06, Julian Seward <julian at valgrind.org> wrote:
> > >   It would be great if I could have help profilling ksysguard.
> >
> > Ok.  Here's what I did to get some profile data for the KDE 3.4.2
> > supplied on SuSE 10.  I decided to profile it using Josef W's
> > excellent "callgrind" profiler.
> >
> > I used the latest V sources because I happen to have them sitting
> > around on my machine :), because they are generally faster and
> > more robust than 3.1.1, and also because they contain callgrind as
> > a standard tool (unlike 3.1.1).  I suggest you do the same.  Easy:
> >
> >   svn co svn://svn.valgrind.org/valgrind/trunk valgrind
> >   cd valgrind
> >   ./autogen.sh
> >   ./configure --prefix=...
> >   make
> >   make install
> >
> > (see http://valgrind.org/downloads/repository.html for details)
> >
> > Since I did not know what bunch of processes ksysguard would create,
> > nor which are the important ones, I profiled all of them:
> >
> >   valgrind --tool=callgrind --simulate-cache=yes \
> >            --trace-children=yes -v ksysguard
> >
> > After a couple of minutes the app appeared.  I let it run for about
> > 20 minutes (you don't need to wait that long, but I did).  There were
> > 2 running processes taking up 100% CPU between them (remember, programs
> > run much slower under V).  Then I quit the app.
> >
> > The result is these 3 log files
> >
> > -rw-------   1 sewardj users  387788 2006-05-08 19:51 callgrind.out.21650
> > -rw-------   1 sewardj users       0 2006-05-08 19:51 callgrind.out.21652
> > -rw-------   1 sewardj users 4459626 2006-05-08 20:11 callgrind.out.21651
> >
> > I don't know what's with the .21652 one.
> >
> > I loaded the other two into the kcachegrind GUI (kcachegrind is a
> > standard part of KDE, I believe).  The .21650 one did not look
> > that interesting, but I did not know what I was looking at.  .21651
> > contains a lot more detail.  I switched to the 'cycle estimation' view. 
> > It seems QEventLoop::processEvents consumes 70.15% of the estimated
> > cycles, and the GUI shows lots more info.  Because this is a
> > non-developer build, I only have function names to look at, but if you
> > tell kcachegrind where your sources are and have built with -g (and
> > -O/-O2) you should get details down to the line level.
> >
> > A couple of other comments:
> >
> > - If you're just starting out profiling, you could omit
> >   --simulate-cache=yes.  This provides less useful numbers but it
> >   provides them sooner.
> >
> > - I was surprised that the two active processes (the viewer and the
> >   daemon?) consumed 100% CPU on my desktop 1.7GHz P4.  If we say that
> >   callgrind runs programs 50x slower than native (not sure of the exact
> >   numbers, but it's in that ballpark) then roughly we can say the two
> >   processes natively would take up >= 2% CPU, which seems like a lot
> >   (that's >= 34MHz worth of machine cycles).  So perhaps there's
> >   something expensive in there.
> >
> > Does that help?
> >
> > J