Re: Profiling GTK within an application

[Chris Rorvick <chrisr trdlnk com>]

Ivan Baldo wrote:
>       1 - application code profiling (gprof), it only profiles the 
> code of the application without taking into account the libraries it 
> uses and other factors like X and your h ardware and video card.
>       2 - application code and libraries code profiling (qprof), it 
> only profiles the code of the application and the code of the 
> libraries without taking into account other processes that interact 
> with your application like X and your hardware and video card.

Why do you distinguish these as conceptually distinct types of
profiling?  I'm interested in profiling everything executing within the
address space of my application.  Why should I care if the linking is
done statically or dynamically?  Certainly I won't argue that the tools
I have readily available do not provide me the ability to do this--thus
somewhat the motivation for this post.  But ignoring calls into a shared
library hardly seems like a distinct way of profiling.

>       3 - system wide profiling (sysprof, oprofile), it profiles all 
> code of all proceses including the kernel and drivers.

Clearly not what I'm going for right now, but will keep this in mind.

>    So taking into account all that, one needs to decide what specific 
> kind of profiling it needs, and then find the tool for the job.
>    In your case, you say that "top" is showing that your application 
> process is using more CPU than before, and also you say that the 
> slowdown doesn't come from your application but from a library (GTK+ 
> suite), so I guess that for that case what you need is a profiler that 
> shows you the CPU time used by functions in your code accumulating the 
> time used in the functions that it calls (from GTK+ or your 
> application), that will help determine what functions of your code 
> take the most time to fulfill, and then you can look at those 
> functions to change the way you use GTK+ to optimize your use of GTK+ 
> and avoid the slowdown, or maybe to see what functions of GTK+ are 
> slowing down your application and see if you can optimize that 
> functions in GTK+ itself.

Yes, this generically describes of how I'd like to use the output from a
profiled run.

>    If QProf is compatible with Solaris and you can build it with 
> libunwind then it can show you a call graph of your functions and 
> library functions and the accumulated and segregated times of each, 
> the default mode of operation is to show used CPU time and thats 
> precisely what you need, but you can also instruct it to take into 
> account the time the function sleeps, if you keep your application 
> busy then it will mostly sleep for X or another process or hardware 
> item to finish your request and it could be useful too.

Is this preferable (i.e., easier) to just linking in static versions of
GTK+ libraries that are instrumented with GCC option '-pg'?

>    Since now you know what type of profiling you need, maybe you can 
> ask on a Solaris specific mailing list, forum or IRC channel for that 
> type of profiler.

No thanks, I'd rather ask on a GTK+ list how to go about instrumenting
and profiling this code with GCC within a Solaris environment.  Maybe 
you haven't done this, but I'm sure someone has some bright ideas.