Hi Jon, On Mon, Feb 22, 2010 at 08:43:31AM -0600, Jon Turner wrote: > You're not listening. I am using -pg and the program is statically > linked. The concern I am raising is not about the function counting, > but the reported running times, which are determined by sampling > (read the gprof manual, if this is news to you). > > In this case, the mcount overhead cannot account for the discrepancy, > since that would cause gprof to OVER-estimate the run time, while > in this case it is UNDER-estimating. It's missing about 70% of the > actual running time in the program.
Well, іn fact I expect gprof to UNDER-estimate the runtime: The processor needs time in order to do the profiling (count, how often a function was called from which function; measure the times, ...) Now: - the external "time" command will INCLUDE theses times into the reported runtime (it can't distinguish between operations done by your code and by the profiling-code) - I would expect the profiling code to EXCLUDE theses times - because they only pollute the profiling data: When I try to optimize the code based on the profiling-data, I'm not interested in the question how much time was used for the profiling-code, but I'm only interested in the time used in MY code. So: - "time" will give the total runtime (your code + profiling-code) - the gprof-output will (probably) give the runtime of your code, without the profiling code and that means, that gprof should underestimate the runtime. Well, that's what I believe, I never checked it carefully. In addition, you have another place where gprof underestimates the runtime (as already mentioned): - when you link a library which was compiled without -pg, its runtime will be neglected by gprof, but not by "time". Are the standard-libraries (glibc for example) to which you link compiled with "-pg" ? if not, time spend in "printf" or "std::cout" or ... will be neglected by gprof too. - when you call a Kernel-function, which runs in Kernel space, it will be included by "time" - but not by "gprof". HTH, Axel
