Helping with KDE4 (valgrind)

[John Tapsell]

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
>