Speedprof profiler

[Soeren Sandmann <sandmann daimi au dk>]

I promised several people at GUADEC that I would write a mail to
gnome-hackers explaining where to get the speedprof profiler and a bit
about the part of my talk that I didn't get to before running out of
time. 

A version of memprof with my patch applied is available at

        http://www.daimi.au.dk/~sandmann/memprof-0.5.1-ssp.tar.gz

After compiling and installing, you should be able to run the profiler
by typing "speedprof". If you type "memprof", you'll get the original
memory profiler.

I did get permission from Owen to actually commit the patch to memprof
CVS, so I hope to be able to do an actual memprof release fairly soon
with the necessary patches applied.

Probably the most interesting part of speedprof is the way it handles
recursions. A gtk+ program is usually highly recursive because signals
will very often be emitted within signal handlers causing the
g_signal_emit() function to recurse deeply.

Suppose an application has three signals, s1, s2 and s3, where the
handler for s1 emits s2 whose handler emits s3. The stack traces for
this application would look like this

        g_signal_emit s1
        g_signal_emit s1 g_signal_emit s2
        g_signal_emit s1 g_signal_emit s2 g_signal_emit s3

If you look at this application in speedprof and selects s1 in the
left pane, you'll see a tree that looks like this

        s1
        |
        +- g_signal_emit
           |
           +- s2
           |
           +- s3

Each row of the tree will have numbers associated with them. The way
this tree should be interpreted is that s1 called g_signal_emit() and
g_signal_emit() called s2 and s3 when g_signal_emit was called from
s1.

The information left out here is that s3 is actually a descendant of
s2. If you need that information you'll have to select the s2 function
in the left pane.

To see why it is done this way, consider an application that has two
mutually recursive function f1 and f2. A complete call tree for this
application would become very deep. Instead the view for two mutually
recursive functions foo() and bar() would be just this when foo() was
selected:

        foo
        |
        +- bar 

which is much more useful because the times for foo and bar are
collected in only one place. 

In the g_signal_emit() case it *would* be useful to have a complete
and accurate call tree, because in that case what we are seeing is not
recursion in the usual sense of the word, but basically a funky way of
doing function calls. I might add this feature ("ignore recursions
for") to speedprof at some point.

I hope this explanation wasn't too unclear. I don't think it is
necessary to grok all the details to just use the profiler, as long as
you understand that the tree in the right pane is not an accurate
representation of the call tree.


Søren