Red Gate forums :: View topic - Profiling
Return to RSS Feed Available

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


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

Joined: 10 Oct 2011
Posts: 2

PostPosted: Mon Oct 10, 2011 5:26 pm    Post subject: Profiling Reply with quote


I have an application (VB.NET Framwork 2.0) that runs continuously that opens our business objects and saves them. When I profile with PerfMon my #Bytes in All heaps eventually will rise to about 1.2 gig then application will get an "Out of Memory" exception (after about 3 hours). When I profile with Ants Memory profiler (version 7.1) my application will run for many days and never exceed 250 meg (# Bytes in All Heaps) and will successfully finish. Please note my application is running with debugging compiled in, which I am aware that their is an issue with __ENCList (weak reference objects). Is ants profiler somehow getting rid of these objects? I don't understand why memory will behave differently while profiling with Ants opposed to PerfMon. Any help or guidance would greatly be appreciated.

Rob Panosh
Advanced Software Designs
Chesterfield MO
Back to top
View user's profile Send private message

Joined: 17 Aug 2006
Posts: 137

PostPosted: Tue Oct 11, 2011 11:48 am    Post subject: Reply with quote

I don't think that the memory profiler will make any noticeable difference to the way that weak references behave.

The biggest difference that you will see with the profiler attached to a desktop app is that it will disable concurrent garbage collection. Until you click 'take snapshot' for the first time, there won't be any other major differences in application behaviour except that garbage collections will take longer (but only noticeably longer after the first snapshot has been taken in most cases)

You can edit your applications config file to disable this mode yourself and see if you get the same effect. See for details on the setting.

The most likely cause that I know of for this kind of problem is large object heap fragmentation. Garbage collection timing can affect how this turns out, so the change in mode could explain the behaviour you're seeing. You can tell for sure if the Large Object Heap bytes counter is very high at the point when your application crashes (outside the profiler).

You might be able to solve this issue by adding a GC.Collect() to the appropriate part of your code: it's not ideal because there will be a performance hit. The memory profiler can help a bit with identifying which objects are likely to be responsible: take two snapshots a reasonable distance apart (long enough that you'd expect to have seen an issue) and set the filters to show new objects that are on the large object heap: it's likely that you need to force a collection whenever these objects are freed up. Alternatively, you might want to cache and recycle them, or rewrite the code so that it only uses small arrays.
Andrew Hunter
Software Developer
Red Gate Software Ltd.
Back to top
View user's profile Send private message

Joined: 10 Oct 2011
Posts: 2

PostPosted: Tue Oct 11, 2011 5:04 pm    Post subject: Reply with quote


Thanks for your reply. After forcing garbage collection after our update, which is a very deep recursive call, it seem to fix our issue.

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