The run-time figures that
gprof gives you are based on a sampling
process, so they are subject to statistical inaccuracy. If a function runs
only a small amount of time, so that on the average the sampling process
ought to catch that function in the act only once, there is a pretty good
chance it will actually find that function zero times, or twice.
By contrast, the number-of-calls figures are derived by counting, not sampling. They are completely accurate and will not vary from run to run if your program is deterministic.
The sampling period that is printed at the beginning of the flat profile says how often samples are taken. The rule of thumb is that a run-time figure is accurate if it is considerably bigger than the sampling period.
The actual amount of error is usually more than one sampling period. In
fact, if a value is n times the sampling period, the expected
error in it is the square-root of n sampling periods. If the
sampling period is 0.01 seconds and
foo's run-time is 1 second, the
expected error in
foo's run-time is 0.1 seconds. It is likely to
vary this much on the average from one profiling run to the next.
(Sometimes it will vary more.)
This does not mean that a small run-time figure is devoid of information. If the program's total run-time is large, a small run-time for one function does tell you that that function used an insignificant fraction of the whole program's time. Usually this means it is not worth optimizing.
One way to get more accuracy is to give your program more (but similar)
input data so it will take longer. Another way is to combine the data from
several runs, using the `-s' option of
gprof. Here is how:
gprof -s executable-file gmon.out gmon.sum
gprof executable-file gmon.sum > output-file