mlprof is right (I think) (but I have improvements)

[Henry Cejtin]

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.