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

Bob <(E-Mail Removed)> wrote:
> 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.

--
Jon Skeet - <(E-Mail Removed)>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

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

John

"WJ" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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.

Using profiler.

HTH
Alex

"Willy Denoyette [MVP]" <(E-Mail Removed)> wrote in message
news:%23WbcUS$(E-Mail Removed)...
>
> "WJ" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
> > 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.
>
>

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" <(E-Mail Removed)> wrote in message
news:%23zNAVn$(E-Mail Removed)...
> Using profiler.
>
> HTH
> Alex
>
> "Willy Denoyette [MVP]" <(E-Mail Removed)> wrote in message
> news:%23WbcUS$(E-Mail Removed)...
>>
>> "WJ" <(E-Mail Removed)> wrote in message
>> news:(E-Mail Removed)...
>> > 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.
>>
>>
>
>

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?


"Willy Denoyette [MVP]" <(E-Mail Removed)> wrote in message
news:%23%(E-Mail Removed)...
> 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" <(E-Mail Removed)> wrote in message
> news:%23zNAVn$(E-Mail Removed)...
> > Using profiler.
> >
> > HTH
> > Alex
> >
> > "Willy Denoyette [MVP]" <(E-Mail Removed)> wrote in message
> > news:%23WbcUS$(E-Mail Removed)...
> >>
> >> "WJ" <(E-Mail Removed)> wrote in message
> >> news:(E-Mail Removed)...
> >> > 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.
> >>
> >>
> >
> >
>
>

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

"Bob" <(E-Mail Removed)> escribió en el mensaje
news:#(E-Mail Removed)...
> 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
>
>

Inline

Willy.

"AlexS" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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.