compiz team mailing list archive

[Daniel van Vugt <vanvugt@xxxxxxxxx>]

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.

-- 
You received this bug notification because you are a member of compiz
packagers, which is subscribed to compiz in Ubuntu.
https://bugs.launchpad.net/bugs/888039

Title:
  Gradual degradation in desktop performance.

To manage notifications about this bug go to:
https://bugs.launchpad.net/compiz/+bug/888039/+subscriptions