how to check the memory usage of an object at runtime?

[Bob]

I'm trying to decide on what data types to put into my caching object (a
class with a static instance of Hashtable). I'm facing the choice of either
putting the string values or SqlParameter objects into the Hashtable.
There'll be a couple of hundred of these values. If the SqlParameter
objects don't eat up too much memory comparing to the strings, I'd very much
like to go with the SqlParameters. How can I check the memory usage of my
static class (or rather the static instance Hashtable) at runtime when it's
loaded with the data? I tried the SciTech .NET Memory Profiler but not sure
what I was looking at.

Thanks a lot
Bob

 

[Jon Skeet [C# MVP]]

I'm trying to decide on what data types to put into my caching object (a
class with a static instance of Hashtable). I'm facing the choice of either
putting the string values or SqlParameter objects into the Hashtable.
There'll be a couple of hundred of these values. If the SqlParameter
objects don't eat up too much memory comparing to the strings, I'd very much
like to go with the SqlParameters. How can I check the memory usage of my
static class (or rather the static instance Hashtable) at runtime when it's
loaded with the data? I tried the SciTech .NET Memory Profiler but not sure
what I was looking at.

I don't know the details of SqlParameter, but I very much doubt that
having a couple of hundred of them would make any significant
difference.

 

[WJ]

You may want to use the Size of the class to determine the amt. of ram your
object use.

John

 

[Willy Denoyette [MVP]]

You may want to use the Size of the class to determine the amt. of ram
your object use.

John

And how do you think you can get at the size of the class at run-time?

Willy.

 

[AlexS]

Using profiler.

HTH
Alex

And how do you think you can get at the size of the class at run-time?

Willy.

 

[Willy Denoyette [MVP]]

This is not what I call at run-time! You can't call profiling API's from
managed code, you can only attach a profiler to a running managed process.

Willy.

 

[AlexS]

Somehow I can't agree with "can't call". But this is not the issue, right?
If you attach before object is created and then check heap and allocations
after you create and use object, doesn't this give you the required
information?

 

[Dejan Lukovic]

Hi Bob,

there is posibility to check object size at runtime by simply using SOS
debugger. Of course, you can use it from IDE or using "Debugging Tools for
Windows" (ADPPlus).
In both cases you should load SOS debugger (.load sos.dll) and execute
commands like
!dumpheap -type <your class>
pick memory address of that class and get
!objsize <address>
You will get your values.

There is an great article on similar topic at
http://www.csharphelp.com/archives4/archive622.html to start with this.

Of course you should take a look about SOS debugger at Microsoft site.

Best regards,
Dejan Lukovic

 

[Willy Denoyette [MVP]]

Inline

Willy.

Somehow I can't agree with "can't call". But this is not the issue, right?
If you attach before object is created and then check heap and allocations
after you create and use object, doesn't this give you the required
information?

Sure, but this is what the OP did with the SciTec profiler, and this didn't
seem to fit the bill.
<snip
I tried the SciTech .NET Memory Profiler but not sure
what I was looking at.
/snip>

I guess what the OP wants is to check the object size from within his code.
Note that a profiler only gives you the size of your individual objects not
the size of the object graphs, that means if the object is a container, it
only gives you the (actual) size of the container NOT including the
contained objects. So to get the real object size you have to walk the graph
and add the sizes of the sub-objects to the size of the container, which is
not a trivial task. The final result is the total size of an object graph
that might change over time depending on the size of the subobjects (strings
f.i), so in fact it only gives you a raw estimate, something that's not
worth the trouble IMO.

Willy.