Memory profiling datasets

[SCPP]

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

[Brian Donahue]

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/Content?c=ANTS_Memory_Profiler%5chelp%5c7.1%5camp_filtering_overview.htm&p=ANTS%20Memory%20Profiler
_________________
Brian Donahue
Technical Support
Red Gate Software Ltd.
44 (0)870 160 0037 ext 8521
US and CAN 1-866-RED GATE ext 8521

[SCPP]

[Brian Donahue]

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
Technical Support
Red Gate Software Ltd.
44 (0)870 160 0037 ext 8521
US and CAN 1-866-RED GATE ext 8521

[SCPP]

[Brian Donahue]

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
Technical Support
Red Gate Software Ltd.
44 (0)870 160 0037 ext 8521
US and CAN 1-866-RED GATE ext 8521

[AndrewH]

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

[SCPP]

[SCPP]