Thu, 2 Jan 2003 10:45:24 -0800
> First of all, best wishes for 2003 !
Thanks Alain. Happy New Year to you and everybody else as well.
> I saw your commit of the profiler and read about the severe time penalty
> it causes.
> I also notice your hint of a new idea of yours to attempt to overcome it
> and was curious to known more about it.
> Are you thinking of decreasing the cost of repeated stack scans by
> either caching walk of stack subsegments or by simply decreasing the
> frequency of timer interruptions ?
Neither. I thought a little about caching the stack walk but couldn't
think of any way to do it. And I don't think decreasing the frequency
of timer interruptions will help. Sometimes the stack just has too
So, I'm going back to the suggestion that you made earlier -- to keep
a global count of clock ticks, store its value when a function is
first pushed on the stack and, when the function is removed from the
stack to bump the counter by the delta in clock ticks. This is
similar to what I do know for allocation profiling. The reason I
didn't consider it for time stack profiling is that I thought that the
overhead would be too high. And indeed, the allocation stack
profiling had much more slowdown than the time profiling in all the
cases except for those where the stack is large (like merge and self
The new idea that I had last night that I think may make the overhead
acceptable, and is at least worth trying, is to only use your
suggestion when making an SSA nontail call, not for all enters and
leaves (i.e. not for source functions that are inlined or contified).
That's what I'm planning on trying. With all the infrastructure in
place, and a couple of previous profiling passes under my belt, I
should be able to get it working in a day or two.
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
MLton-devel mailing list