profBug

[Matthew Fluet]

> 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.

Well, now that things are becoming a little more clear, I could go either
way.  I'm going to leave the '-s' option meaning to include static
functions for now, because that seems more natural to me.

> 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.

I agree.  The root issue was mine, where I had the interpretations of 'T'
and 't' backwards.  It should be fixed now, and you will get the same
counts with or without the -s flag.

> 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.

What's wrong with that theory?  I uses '.' in the MLtonProfile labels, but
I've got a separate regexp checking for those; if we fail on that regexp,
then I use the label regexp rewritten from Steve's ML translation of the
Python profiler.

> 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.

O.k., although I'm not sure what information you're getting when not
displaying static functions.  I guess the ideal case is code like the
following:

int f (...) {...}
int f_auxA (...) {...}
int f_auxB (...) {...}

int g (...) {...}
int g_auxA (...) {...}

Assuming f and g are non-static and f_auxA, f_auxB, and g_auxA are static,
then all time between the label for f and the label for g would be
attributed to f -- so now time in f_auxA would be given to what we expect
to be the calling function.   O.k., this makes sense, but obviously there
are many places where this breaks down; personally, I prefer to write
bottom-up.

Anyways, I restored mlprof to the old behavior.

> 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.

True.  But it was mostly just a warning -- once we're happy with the
processing of the true C functions, I suspect you'll take a look at the ML
functions.  Anyways, the vanishing labels was the static vs. non-static
problem, which is now resolved. (fingers crossed.)