profBug

[Henry Cejtin]

Ok,  sorry  for  the minor problem of the 2.47% vs. 2.51%.  The silly program
that I was using to look at the bins had an off-by-one  error,  so  that  was
definitely my confusion.

Once  again,  `t'  means static and `T' means non-static in the nm output.  I
agree that it might make more sense to have the `-s' option mean  to  include
static  functions,  although in both the version I originally wrote in Python
and Steve's ML rewrite it was the other way around.  I did it that  way  just
because usually I want static so I made it default.

Either      way,      since      neither     GC_foreachPointerInRange     nor
GC_foreachPointerInObject are static, nor are the routines surrounding  them,
I don't see why the -s flag should have any effect on their timings.

Again,  `T'  is  non-static  and `t' is static.  The thing with `.' in symbol
names, if I am reading symbolRegexp correctly, was only to avoid  the  symbol
`gcc2_compiled.',  which  is  inserted  by  gcc, and is of type static.  This
symbol should always be ignored.  In the Python code I removed  symbols  with
`.'  in  them  because  you can't have such symbols in C, so I knew that they
were garbage and  figured  it  would  be  a  more  long-lived  solution  than
explicitly removing `gcc2_compiled.'.  So much for that theory.

The idea (not a great one, but what most profilers do in desparation) is that
if you are NOT including static functions, then you assume each  global  name
covers  from  its value until the next global names value.  This works if you
write your C code in top-down style (so static will come  after  non-statics)
and  the C compiler preserves the ordering.  As much as this can fail, I much
prefer it to combining all the statics into `<static>' since that  is  pretty
worthless.   Just  because all the static functions together took most of the
time doesn't mean that `<static>' should be listed as a  hot  spot.   Thus  I
would  change  the  case  with `-s' specified back the way it was, but again,
that still doesn't explain the non-statics vanishing.

Similarly with the mlton changes, I agree that the alignment directives being
placed  between the profiling labels and the actual branch points is going to
cause some errors (around the edges), but none of this explains the vanishing
GC_foreachPointerInRange or GC_foreachPointerInObject.