Effect of properties or get/set methods on object size

Question

In terms of object size, how do properties instead Get/Set methods affect object size if the exposed properties do not represent a state but simply delegate its getter and setter calls to another entity?

For example, consider the following classes:

public class Person
{
   Address _address = new Address();

   public string AddressName
   {
      get{ return _address.Name; }
      set { _address.Name = value; }
   }

   public string GetAddressName(){ return _address.Name; }
   public void SetAddressName(string name){ _address.Name = name; }

}

public Address
{
    public string Name { get; set; }
}

I am guessing that when a new Person is created, the CLR will take into consideration the potential size of AddressName property when determining how much memory to allocate. However, if all I exposed was the Get/Set AddressName methods, there will be no additional memory allocated to cater for an AddressName property. So, to conserve memory footprint, it is better in this case to use Get/Set methods. However, this will not make a difference with the Name property of the Address class as state is being preserved. Is this assumption correct?

Answer 1

The size of an individual object is not affected by the number of properties, methods, events etc. It affects the size of the type metadata, and the JITted code - but not the per-object size. That's only affected by instance fields.

I am guessing that when a new Person is created, the CLR will take into consideration the potential size of AddressName property when determining how much memory to allocate.

No. It only looks at your fields. You have a single field (_address) so that plus the normal object overhead are all the memory required for a single instance.

Answer 2

As Jon already answered, the size of an object instance is determined only by its instance fields. However, let me go into a little bit more detail.

An object instance is at the very least as big as the sum of the sizes of its fields. Depending on field alignment constraints and the way the CLR (Common Language Runtime) layouts the fields, some padding bytes may need to be taken into account. For reference types, an instance has two additional hidden fields: the sync block index and the type reference. Both are native integers. On the heap, instances have a minimum size of 12 bytes (regardless of how much space they actually need).

Take for example the following class:

class X
{
    byte value1;
    string value2;
    int value3;
    long value4;
}

On a 32-bit system, an instance of X may require 28 bytes:

• 2 times four bytes for the sync block index and type reference,
• one byte for byte,
• three padding bytes, to align the next field,
• four bytes for the object reference string,
• another four bytes for int
• and eight bytes for long,

As you can see, the getters and setters, methods and constructors do not take up space in each object instance. Instead, there is a separate object (which you know as Type) that maintains a list of methods (getters, setters and constructors are also methods) and contains the static fields of the type. You can create as many object instances of a type as you want, but there will only be one Type object for any given type instance.