Red Gate forums :: View topic - Memory profiling datasets
Return to www.red-gate.com RSS Feed Available

Search  | Usergroups |  Profile |  Messages |  Log in  Register 
Go to product documentation
ANTS Memory Profiler 7
ANTS Memory Profiler 7 forum

Memory profiling datasets

Search in ANTS Memory Profiler 7 forum
Post new topic   Reply to topic
Jump to:  
Author Message
SCPP



Joined: 23 Aug 2011
Posts: 7

PostPosted: Wed Aug 24, 2011 12:39 am    Post subject: Memory profiling datasets Reply with quote

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
Back to top
View user's profile Send private message
Brian Donahue



Joined: 23 Aug 2004
Posts: 6673

PostPosted: Thu Aug 25, 2011 10:11 am    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
SCPP



Joined: 23 Aug 2011
Posts: 7

PostPosted: Mon Aug 29, 2011 3:00 am    Post subject: Re: Reply with quote

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
Back to top
View user's profile Send private message
Brian Donahue



Joined: 23 Aug 2004
Posts: 6673

PostPosted: Mon Aug 29, 2011 11:38 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
SCPP



Joined: 23 Aug 2011
Posts: 7

PostPosted: Tue Aug 30, 2011 1:58 am    Post subject: Re: Reply with quote

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
Back to top
View user's profile Send private message
Brian Donahue



Joined: 23 Aug 2004
Posts: 6673

PostPosted: Tue Aug 30, 2011 9:36 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
AndrewH



Joined: 17 Aug 2006
Posts: 137

PostPosted: Tue Aug 30, 2011 2:17 pm    Post subject: Reply with quote

'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.
Back to top
View user's profile Send private message
SCPP



Joined: 23 Aug 2011
Posts: 7

PostPosted: Wed Aug 31, 2011 5:28 am    Post subject: Re: Reply with quote

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
Back to top
View user's profile Send private message
SCPP



Joined: 23 Aug 2011
Posts: 7

PostPosted: Wed Aug 31, 2011 5:29 am    Post subject: Re: Reply with quote

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?
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic All times are GMT + 1 Hour
Page 1 of 1

 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group