[Mono-devel-list] Profiler Idea

[Ben Maurer]

On Wed, 2004-01-14 at 11:26, Paolo Molaro wrote:
> On 01/13/04 Ben Maurer wrote:
> > > > Now, obviously, I have seen this method before. But for the first time
> > > > today, I reflected on how useless this data was. You get no idea *WHO*
> > > > is calling the method.
> > > 
> > > The first part of the profile output has the call info, so you just need
> > > to see which methods call ToCharArray(int,int).
> > yes, however this gets really hard to do, and makes it hard to get a
> > general overview of things.
> 
> Hence the suggestion I made in my mail.
> 
> > Well, the idea is to detect `who is causing the most space to be
> > allocated in the hashtable.' For example this code:
> > 
> > for (..) {
> > 	for (..) {
> > 		ht.Add (...);
> > 	}
> > 	ht.Clear ();
> > }
> > 
> > is much better than:
> > 
> > for (..) {
> > 	for (..) {
> > 		ht.Add (...);
> > 	}
> > }
> 
> The code does different things semantically, so saying it's much better
> doen't make sense.
I know that. My point is, that the first results in O(1) rehashes,
wheras the second results in O(lg (n)) [or something of that type].
(where n is the number of executions of the line with .Add). You cant
tell that from the current profiler data.

> If Bar() allocates 10% of the total amount of memory allocated by Foo(),
> it's correct for it to be less prominent in the profile, that's the
> point of the memory profiler. On the other hand if really Bar() is
> allocating most of the memory allocated by Foo(), they will be close at
> the top of the profile, ie, exactly what the profiler should give.

Well, when I work on a program the first question I try to tackle is:

`What functions are allocating too many temporary Arrays/Hashtables,
etc'

In that case, if all the other children of Foo allocate 1% of the
memory, Bar is going to be my first target.

I do agree, it would be nice to have a mode where you see memory
allocations attributed to all the parent functions. I think it serves a
different purpose, for when you want to figure out, `how do i change the
behavior of my program'.

> > cant tell the difference between Foo and Bar becuase they make the same
> > number of calls to the ctor. The kind of data that would be most useful
> > in this case is:
> > 
> > #######################
> > Driver::Bar
> >              500 object [] (xxxxxxxx KB) (via MyList.ctor)
> 
> Keeping that level of detail is very expensive. Distributing the
> allocated amount using call arcs provides a good enough picture of what
> is happening.

Do you think it would make the code useless? We could move the memory
profiler outside of the main timer profiler.