mlprof is right (I think) (but I have improvements)
Henry Cejtin
henry@clairv.com
Fri, 9 Jul 1999 23:21:19 -0500
I just looked again at the gmon.out numbers (more or less by hand) and, for
instance, it really is true that there were 5,181 ticks in forward (out of
30,312 ticks total). This makes sense. Basically I am looking mostly at the
-sf version and -dsf version.
There are still two possible causes of error:
1) All the profiling works by mapping the program counter to a bin and
then incrementing the bin. Each bin covers 4 bytes, and I consider
[x, x+4) to really be x+2. Looking at the raw bins shows that this
is unlikely to be the cause of much error.
2) Even my by-hand looking uses the Python code to convert the gmon.out
file into a list of bins (each bin = first address, one past last
address and count). There are no standard tools to do this, and I
deduced it from looking at the file. I could be wrong. I really
REALLY doubt that 2 is the case either.
I did tests with functions that were huge and spent all their time in one
spot and I always hit it on the nose. I really think that the numbers are
right.
Note, it isn't really fair to charge all the copying overhead (from C
variables to the array) as C overhead. If the variables are in registers,
any code is pretty much going to have to do something similar.
Still, I really am starting to believe mlprof. There is a HUGE improvement
possible.