[Mono-list] profiling mono

[James Roberts]

--- Michael Meeks <michael@ximian.com> wrote:
> > To achieve such low overhead, we plan on using a
> > statistical sampling process
>
> Why ? The real usefulness of OProfile surely is for
> complete system profiling, 
> across kernel / user-space /
> cross-process and taking full
> system call latencies into account.
> 
> Of course - none of this is that interesting wrt.
> improving the performance of JIT'ing, ( though
> fairly interesting for system
> optimisation ).
> 

Two parts:

1)Why sampling as opposed to instrumented method
preambles?

It is my humble opinion that low overhead (on the
order of less than 10%) will not be achievable via
binary instrumentation.  With instrumentation you get
an overload of information.  By observing the exact
behavior of an application, the data comes in very
rapidly and at a granularity that really isn't
necessary for making a rough characterization of the
program's behavior (which is what we are interested in
doing).  In this case, I think statistical sampling is
the way to go.  Sampling may not be 100% accurate, but
the low overhead associated with sampling makes the
trade-off worthwhile.

Additionally, statistical sampling offers the
possibility of dynamically adjusting the rate of
sample collection (e.g. make rapid collections at
phase-transitions, and then reduce the sampling
frequency under steady-state conditions). 
Instrumentation, however, is always on, or atleast
more difficult to adjust.

2) Why OProfile?

OProfile does most everything we want to do.  It is an
existing piece of code that is able to leverage
hardware mechanisms for collecting profile data (and
does so at very low overhead).  Yes, OProfile is
probably overkill for this problem, but its facilities
can be scaled down for what we need it to do.

> So it seems to me that instrumenting the generated
> code, and/or having access to some sufficiently
> high-speed (better than itimer) timer, will
> give you more joy. Especially since you really want
> to look at more of the stack trace than the
> immediate PC gives you - [AFAICS PC
> measurements are mostly useless for optimisation /
> esp. inlining ].
> 

The high-speed timer is an idea I'd be willing to
consider as an alternative to OProfile.  If we could
somehow integrate the timer mechanism into the Mono
runtime, perhaps we could get more detailed
information than just PC addresses (as would happen
with OProfile).

Any suggestions on that?  What kind of timer did you
have in mind?

-James


__________________________________________________
Do you Yahoo!?
U2 on LAUNCH - Exclusive greatest hits videos
http://launch.yahoo.com/u2