Helping with KDE4 (valgrind)

[Josef Weidendorfer]

On Monday 08 May 2006 23:45, Julian Seward wrote:
>   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.

OK, I too, did a quick run (without the cache simulator).
The empty one seems to come from the daemon (I can do a dump with callgrind_control).
No idea why it does not dump at termination :-(

In ksysguardd, 55% of instructions are executed in _IO_vfscanf, which is called
both from fscanf and sscanf. Despite running only a few seconds, both of these
functions where called >100000 times. I suspect this is parsing the /proc files?
Probably a specially written parser would be good here...
However, ksysguardd takes perhaps 1/6 of ksysguard, so it is not that important.

Regarding ksysguard: KSGRD::SensorShellAgent::msgRcvd is taking 60% inclusive
of all executed instructions.
A fast check gives that a lot of time is spent in updating and sorting QListItems.
Thats strange, as I had the process list in the background and the system load
worksheet with the 4 diagrams at top (with no list widgets).
It seems you are updating hidden widgets, which is a waste of time.

This is for KDE 3.5.2, but I suspect that could be the case with KDE 4, too?
Or was this changed with the model-viewer lists in Qt4?

> - 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,

Yes. Top shows ksysguard with around 2% - 3% for me, which is really high.

Josef

>   which seems like a lot 
>   (that's >= 34MHz worth of machine cycles).  So perhaps there's
>   something expensive in there.
> 
> Does that help?
> 
> J
> 
>