Re: Profiling GTK within an application

[Murray Cumming <murrayc murrayc com>]

On Mon, 2007-10-29 at 12:47 -0500, Chris Rorvick wrote:
> Stefan Kost wrote:
>  > This is most likely caused by cairo. You should also see a bit less
>  > CPU usage in 2.12 compared to 2.10 (or more precise newer cairo should
>  > perform a bit better).
> 
> For some reason, this happens to be one of two libraries that I'm
> statically linking in.  I wasn't seeing a lot of time spent in it when
> looking at the gprof report.
> 
> > I would suggest to use a sampling profiler, like oprofile, sysprof,
>  > but all those are linux profilers (they need a kernel module). But I
>  > am sure there a sampling profilers for solaris too. The advantage is
>  > that you don't need to recompile your apps (given you have debug
>  > symbols alreday) and it works with shared libs too.
> 
> I figured out that Sun's dtrace tool allows me to basically script a
> sampling profiler just as you describe.  Very cool program.  My program
> is spending more than 50% of its userland time executing code in glib,
> and a vast majority of that is split evenly between two functions:
> g_slist_find() and g_slist_remove_all().
> 
> I'm going to have to do some more work to figure out the context in
> which these functions are being invoked, but I'm making progress!  :)

If it's only processor-bounds stuff (rather than io-bound) like this
that you are worried about, kcachegrind is a wonderful way to discover
this.

-- 
murrayc murrayc com
www.murrayc.com
www.openismus.com