[Mono-devel-list] Profiler Idea

Paolo Molaro lupus at ximian.com
Wed Jan 14 11:26:24 EST 2004


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.

> > >       * For other select methods and classes, we shall apply a similar
> > >         rule. For example, ToCharArray would be attributed to the method
> > >         that called the 0 args overload.
> > 
> > I don't think adding special case hacks is a good thing.
> > It would be better if, for each method, we could also output the total
> > amount of memory allocated (by the method and by the called methods as
> > well).
> Hmmm, i am on the fence about including child methods. On the one hand,
> I usually try to catch single methods that are causing problems, but
> this method also provides a good approach.

Calculating the memory allocated in called methods doesn't prevent
displaying the amount of memory allocated directly.

> class Driver {
> 	static void Main () {
> 		for (int i = 0; i < 500; i ++) Foo ();
> 	}
> 	
> 	static void Foo () {
> 		MyList l = new MyList (3);
> 		Bar ();
> 		...
> 	}
> 	static void Bar () {
> 		MyList l = new MyList (50000);
> 
> 	}
> }
> 
> In this code, Bar is obviously taking up the most memory. With your
> suggestion, It would be easy for Bar to get lost in the shuffle, if it
> were only responsible for 10% of the allocations of Foo. Right now, you

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.

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

lupus

-- 
-----------------------------------------------------------------
lupus at debian.org                                     debian/rules
lupus at ximian.com                             Monkeys do it better



More information about the Mono-devel-list mailing list