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. -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
