Memory Usage for Objects

[=?Utf-8?B?VG9tKys7?=]

When I create an object in VB.NET I define both properties (data) and methods
(code). If I have 1,000 instances of this object stored in a Dictionary as
Dictionary(of int32, object) then I am obviously repeating the data of the
object 1,000 times.

If I understand correctly how objects are constructed, the methods (code) is
only stored once in memory and referenced by each instance of the object.
Thus it does not matter how many methods I have in an object when it comes to
efficiency and memory usage.

When is it a best practice to keep the object "lightweigh t" (with minimal
code)? Is this the case when we are remoting objects? Are there other reasons
to keep objects that are in collections "lightweigh t"?

--
Tom Stevens

[=?UTF-8?B?R8O2cmFuIEFuZGVyc3Nvbg==?=]

Re: Memory Usage for Objects

Tom++; wrote:

When I create an object in VB.NET I define both properties (data) and methods
(code).

Properties are not data. The member variables of an object is the data.
Properties are just methods used to access the data.

If I have 1,000 instances of this object stored in a Dictionary as
Dictionary(of int32, object) then I am obviously repeating the data of the
object 1,000 times.
>
If I understand correctly how objects are constructed, the methods (code) is
only stored once in memory and referenced by each instance of the object.
Thus it does not matter how many methods I have in an object when it comes to
efficiency and memory usage.

Correct.

When is it a best practice to keep the object "lightweigh t" (with minimal
code)? Is this the case when we are remoting objects? Are there other reasons
to keep objects that are in collections "lightweigh t"?

Light weight refers to the data members of an object, not the methods.
As the number of methods doesn't impact the size of the object
instances, it's very rarely a concern at all. I don't know of any
sitation at all where it would matter.

--
Göran Andersson
_____

http://www.guffa.com

[Linda Liu [MSFT]]

RE: Memory Usage for Objects

Hi Tom,

I agree with Anderson that the properties in a class are methods, not data.

What you described about how objects are constructed is correct.

In my opinion, even if each object has a lot of member variables, it
wouldn't cause the program to perform worse, because it won't add too much
of the object size.

If you have any concern, please feel free to let me know.


Sincerely,
Linda Liu
Microsoft Online Community Support

=============== =============== =============== =====
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscripti...t/default.aspx.
=============== =============== =============== =====

This posting is provided "AS IS" with no warranties, and confers no rights.

[=?Utf-8?B?VG9t?=]

Re: Memory Usage for Objects

Thank you for your fast response.

Yes, I did mean member variables and not properties.


"Göran Andersson" wrote:

Tom++; wrote:

When I create an object in VB.NET I define both properties (data) and methods
(code).

>
Properties are not data. The member variables of an object is the data.
Properties are just methods used to access the data.
>

If I have 1,000 instances of this object stored in a Dictionary as
Dictionary(of int32, object) then I am obviously repeating the data of the
object 1,000 times.

If I understand correctly how objects are constructed, the methods (code) is
only stored once in memory and referenced by each instance of the object.
Thus it does not matter how many methods I have in an object when it comes to
efficiency and memory usage.

>
Correct.
>

When is it a best practice to keep the object "lightweigh t" (with minimal
code)? Is this the case when we are remoting objects? Are there other reasons
to keep objects that are in collections "lightweigh t"?

>
Light weight refers to the data members of an object, not the methods.
As the number of methods doesn't impact the size of the object
instances, it's very rarely a concern at all. I don't know of any
sitation at all where it would matter.
>
--
Göran Andersson
_____

http://www.guffa.com

>