Re: gprof inaccuracy

[law at redhat dot com]

In message <20030311005322 dot GA20739 at nevyn dot them dot org>, Daniel Jacobowitz writes:
 >On Mon, Mar 10, 2003 at 05:47:04PM -0700, Scott Dudley wrote:
 >> 
 >> pardon the intrusion if this is not the appropriate forum, but i 
 >> couldn't find one that seemed more appropriate.
 >> 
 >> i'm attempting to optimize a program that i didn't write and with which 
 >> i'm not too familiar.  i recompiled with the -pg flag and have been 
 >> analyzing the output of gprof.  i'm growing frustrated by it's apparent 
 >> inaccuracy.  can someone shed light on what i might be doing wrong?  for 
 >> example: total runtime for a test run of the program is 4 minutes.  
 >> gprof tells me that nearly 48% of my time is spent in the function 
 >> getAltCostTypeId():
 >> 
 >> Flat profile:
 >> 
 >> Each sample counts as 0.01 seconds.
 >>  %   cumulative   self              self     total
 >> time   seconds   seconds    calls  us/call  us/call  name
 >> 47.72      2.93     2.93    17021   172.14   172.14  getAltCostTypeId
 >> 
 >> ----------------------------------------------------------------------
 >>                2.93    0.00   17021/17021       main [1]
 >> [2]     47.7    2.93    0.00   17021             getAltCostTypeId [2]
 >>                0.00    0.00   17021/127895      toHead [63]
 >> ----------------------------------------------------------------------
 >> 
 >> i comment out the call to getAltCostTypeId(), recompile, rerun, and it 
 >> still takes 3 minutes, 50 seconds to complete and not the ~2 minutes 
 >> anticipated.  how can i "accurately" identify my most costly blocks of 
 >> code using the gnu tools?
 >
 >I believe that gprof generally uses "user time", not "wall time".  You
 >may want to look for something like oprofile; it sounds like most of
 >your time is spent sleeping (on disk or network IO, probably).
Also note that there is an overhead for profiling, which is hard to
factor out of the gprof results.  That overhead can also skew the results
if there are functions which are called very often, but which do real
little work.


jeff