tags:

views:

45

answers:

1

As CLRProfiler use words like HEAP statistic, OBJECTS finalized, it made me think it will atmost only show boxed struct? So what if the structs are my source of problem? How can I know about it with CLRProfiler??

+2  A: 

According to the documentation

"CLRProfiler is a tool that is focused on analyzing what is going on in the garbage collector heap"

so naturally you'll see various statistics concerning the heap.

Structs are value types, so when they are allocated on their own, they are allocated on the stack. The stack is cleaned up during stack unwind and thus is not subject to garbage collection by the GC. If value types are boxed or more commonly if they are part of a reference type, their values will be stored on the heap.

My guess is that if a struct is a source of your problem it is because your application stores a great number of these. This is typically done using arrays (which is the underlying type of a number of .NET collections). Array is a reference type, so it is stored on the heap. If the array holds structs the values too go on the heap as part of the array instance.

In other words, if you want to inspect standalone structs during runtime, you have to locate them on the stacks of the running managed threads. To be honest I am not too familiar with CLRProfiler so I don't know if it supports that. You can, however, inspect this with debuggers such as WinDbg. If, on the other hand, the struct in question is stored in a collection, you have to locate the instance on the heap.

Brian Rasmussen