[MonoDevelop] [PATCH] Profiler support

[Lluis Sanchez]

El dv 20 de 04 del 2007 a les 19:39 +0200, en/na Ben Motmans va
escriure:
> On 4/20/07, Lluis Sanchez <lluis at ximian.com> wrote:
> > In any case, we should have two add-ins, one with
> > the common profiling code (MonoDevelop.Profiling sounds more convenient
> > that MonoDevelop.Profiler to mee), and another with the heap-shot
> > integration (let's say MonoDevelop.Profiling.HeapShot).
> 
> ok, sounds reasonable.
> though you will probably have to wait about a week until i can provide
> the updated patch since i have a couple of exams coming up next week.
> 
> > creating snapshots is something specific to heap-shot
> the IProfilerSnapshot interface is used to describe a file generated
> by the profiler, maybe a poor choice of name, but that is something
> all profilers share.

Yep, the name is a bit confusing ;-)

> the CreateSnapshot method simply means "tell the current profiler we
> need a file describing the current state of the application".

That's also a bit confusing. Most of profilers don't dump the current
state of the application, but a summary of data collected during the
program execution.

> it does
> not matter if the profiler supports taking multiple snapshots, for
> example: when implementing a profiler that requires the application to
> quit before being able to produce a "snapshot", the CreateSnapshot
> method would simply do the same thing as .Stop()
> 
> > In fact, I'm wondering if the IProfiler interface is really needed.
> the main reasons for this interface are:
> * the SnapshotCreated event that all profilers share
> * the fact that i was thinking outside the current profiler scenarios;
> for example:
> suppose there is a profiler that very precisely logs every single
> detail you can think of between 2 point in time. the starting point
> may not be the same as the moment you start the external process
> (suppose you want to profile a weird memory problem that only occurs
> after 30 minutes, you don't want data of the first 29 minutes messing
> up the report), the Start () method will then be used to let the
> profiler know it should start collecting data

I have a different view about how to support those features, but I think
that your design is also correct, so it's OK to me.

Thanks!
Lluis.