Memory profiling datasets

Memory profiling for .NET developers

Moderators: Luke Jefferson, StephenC, AndrewH, melvyn.harbour, james.billings, Laura Morley, dene.boulton

Memory profiling datasets

Postby SCPP » Wed Aug 24, 2011 12:39 am

Hi,

I'm investigating large memory usage of our application and it has a number of large datasets. However when I find the instances of the datasets, the size, "including children" of the dataset objects is less than the sum of the datatable rows contained.

There are many datatables contained in the datasets and so many datarows in each datatable. Is there any way to make the profiler show the dataset object with the aggregate of all those child objects?

Thanks
SC
SCPP
 
Posts: 7
Joined: Tue Aug 23, 2011 4:35 am

Postby Brian Donahue » Thu Aug 25, 2011 10:11 am

It's hard to tell what's happening with your results from this information, but I'd assume some of your datarow objects are being referenced from somewhere else than the parent DataTable. The first thing I would try would be to go through the steps to check for references left by event handlers. It's pretty common with grid controls to retain references to rows after an event has fired.

http://www.red-gate.com/supportcenter/C ... 20Profiler
Brian Donahue
 
Posts: 6670
Joined: Mon Aug 23, 2004 10:48 am

Re:

Postby SCPP » Mon Aug 29, 2011 3:00 am

Brian Donahue wrote:It's hard to tell what's happening with your results from this information, but I'd assume some of your datarow objects are being referenced from somewhere else than the parent DataTable.


Hi Brian,

I'm sure they are probably referenced elsewhere but the root object that they were created on was the parent DataTable and parent DataSet. If that matters?

Just to clarify, I am checking the size of the DataSet objects when they are filled, not after they are disposed. So all the DataTables are filled with information. What I am seeing in the profiler is the DataTables and DataSets have a low size in memory and the DataRows seem to be of the sizes I expect to indicate they contain real data.

E.g.
DataSet Live Bytes: A few hundred/thousand bytes
DataTable Live Bytes: A few hundred/thousand bytes
DataRows Live Bytes: A few megabytes or more.

If the DataSet included it's child objects in the live bytes, I would expect it to be a superset of the DataTables and DataRows, hence should have a size larger. Am I mistaken in this understanding?

Thanks
SC
SCPP
 
Posts: 7
Joined: Tue Aug 23, 2011 4:35 am

Postby Brian Donahue » Mon Aug 29, 2011 11:38 am

Hi,

For the .NET Garbage Collector, it's all about whether or not another object is holding a reference to the DataRow. The object's lineage is not as important. So for instance if you have a DataRow as part of a DataTable and an event handler references the DataRow, you can dispose the DataTable and the Garbage Collector will still leave the DataRow because something else is referencing it.
Brian Donahue
 
Posts: 6670
Joined: Mon Aug 23, 2004 10:48 am

Re:

Postby SCPP » Tue Aug 30, 2011 1:58 am

Brian Donahue wrote:Hi,

For the .NET Garbage Collector, it's all about whether or not another object is holding a reference to the DataRow. The object's lineage is not as important. So for instance if you have a DataRow as part of a DataTable and an event handler references the DataRow, you can dispose the DataTable and the Garbage Collector will still leave the DataRow because something else is referencing it.


Hi Brian,

I don't think you understand my question. I'm not interested in garbage collection. I'm just accounting for the size of objects in memory.

- SC
SCPP
 
Posts: 7
Joined: Tue Aug 23, 2011 4:35 am

Postby Brian Donahue » Tue Aug 30, 2011 9:36 am

The objects are in memory because garbage collection is not cleaning them up because something has a reference to them. The retention graph should show you those references.
Brian Donahue
 
Posts: 6670
Joined: Mon Aug 23, 2004 10:48 am

Postby AndrewH » Tue Aug 30, 2011 2:17 pm

'Size with children' is an inherently intractable problem when applied to memory, as the structure of memory in .NET is not a simple tree but a graph: this means that the notion of one object 'owning' another is really down to the semantics of the API design.

The memory profiler can't know about this, so it uses a simpler approach. It considers that one object owns another if the 'child' object is further away from a GC root than a 'parent' object. This generally works quite well: it gives an estimate of the amount of memory that will be released by removing a particular object from memory.

If you want to explore a more complicated relationship between objects, the tool to use is probably the instance categoriser in all references mode (the mode selector is in the upper right of the screen): you can either start with the DataSet class and expand to the right to see the DataTables that it is referencing, or start at the DataTable class and expand to the left to see the DataSets that are referenced by them.

In the class list, you might find the 'Referenced By DataSet' filter useful (to see all of the objects that are connected somehow to a DataSet), and maybe also the 'Kept in memory exclusively by DataSet' filter (which gives you the set of objects that are only in memory because of DataSet objects)

If you want to find leaked DataTables, a good combination of filters might be to use is 'objects that implement DataTable' and 'Never Referenced By DataSet' (this will give you all of the DataTables that are still in memory but no longer have an active DataSet object associated with them)
Andrew Hunter
Software Developer
Red Gate Software Ltd.
AndrewH
 
Posts: 134
Joined: Thu Aug 17, 2006 3:44 pm

Re:

Postby SCPP » Wed Aug 31, 2011 5:28 am

AndrewH wrote:If you want to explore a more complicated relationship between objects, the tool to use is probably the instance categoriser in all references mode (the mode selector is in the upper right of the screen): you can either start with the DataSet class and expand to the right to see the DataTables that it is referencing, or start at the DataTable class and expand to the left to see the DataSets that are referenced by them.

In the class list, you might find the 'Referenced By DataSet' filter useful (to see all of the objects that are connected somehow to a DataSet), and maybe also the 'Kept in memory exclusively by DataSet' filter (which gives you the set of objects that are only in memory because of DataSet objects)


Ah yes thanks I will give that a go. Might be the way to approach it.

AndrewH wrote:If you want to find leaked DataTables, a good combination of filters might be to use is 'objects that implement DataTable' and 'Never Referenced By DataSet' (this will give you all of the DataTables that are still in memory but no longer have an active DataSet object associated with them)


Not concerned about leaks here. The system doesn't appear to be leaking memory. Just the datasets are rather large and unfortunately are loading in datasets redundantly (sometimes with different filtering so the data won't be identical).

Thanks
SC
SCPP
 
Posts: 7
Joined: Tue Aug 23, 2011 4:35 am

Re:

Postby SCPP » Wed Aug 31, 2011 5:29 am

Brian Donahue wrote:The objects are in memory because garbage collection is not cleaning them up because something has a reference to them. The retention graph should show you those references.

Brian, again, I'm not chasing leaks.... I'm not asking why GC isn't collecting them. Why do you keep talking about the GC?
SCPP
 
Posts: 7
Joined: Tue Aug 23, 2011 4:35 am


Return to ANTS Memory Profiler 7

Who is online

Users browsing this forum: No registered users and 1 guest