© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0e1f616
(Get the code!)
Michael, I thought about it and using a debugger may be appropriate. Because callgrind (and valgrind in general) will slow down compiz/unity to an almost unusable speed. You won't want to run it that way for long enough to even reproduce the gradual degradation. Also, the "gradual degradation" will be drowned out by the constantly poor performance of running under valgrind/callgrind anyway.
Using gdb you can use the "bt" or "where" commands to show the full call stack, which is useful. HOWEVER there is a lot to get right before the data is useful...
1. You need to choose the correct thread in the compiz process, or else you're looking at a useless stack. Probably thread 1, or whichever thread has "main ()" at the bottom.
2. You need to collect the full call stack (all functions) to be useful, not just one function.
3. You need many samples. A process using 20% CPU will only show you the offending call stack 1 in 5 attempts, on average. The rest of the time it will be idle and show you nothing useful. So you need many many samples.
It seems like a lot of effort to use gdb. In a previous life I used to ask my users to use "pstack" (on Solaris) which is a simple command that did all the debugger steps you need in a single command. If you can find a "pstack" alternative for Linux and run it many times then that would be easiest, fastest, and least invasive to your system.