Profiling

[rpanosh]

Hello,

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.

Thanks,
Rob Panosh
Advanced Software Designs
Chesterfield MO
USA

[AndrewH]

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 http://msdn.microsoft.com/en-us/library/yhwwzef8(v=VS.80).aspx 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.

[rpanosh]

Andrew,

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

Rob