Size of A Class (object) in .NET_问答_开发者_运维开发者技术经验分享

How to determine if a Class in .NET is big or small? Is it measured on how many it's attributes or fields, datatype of its attributes/fields? or return type of methods? parameters of it's methods? access modifier of its methods, virtual methods? thanks..

 class A
{

  string x { get; set; }
}

class B 
{
  int x { get; set; }
}

in this example if I instantiate class A and B like this

 A objA = new A();
 B objB = new B();

Is class objA the bigger one because it holds an String property and objB holds only an Int? although I didn't set any value to it's property. thanks

EDIT: Just to clarify my question

suppose i have a class

public class Member
{
    public string MainEmpId { get; set; }
    public string EmpId { get; set; }
}

and another class

public class User
{
    public string AccessLevel { get; set; }
    public string DateActivated { get; set; }
    public string FirstName { get; set; }
    public string LastName { get; set; }
    public string Mi { get; set; }
    public string Password { get; set; }
    public string UserId { get; set; }
    public string UserName { get; set; }
    public string Active { get; set; }
    public string ProviderName { get; set; }        
    public string ContactPerson { get; set; }
    public string Relation { get; set; }
    public string Landline { get; set; }
    public string MobileNo { get; set; }
    public string Complaint { get; set; }
    public string Remarks { get; set; }
    public string Reason { get; set; }
    public string RoomType { get; set; }
}

if I instantiate it like this

  Member A = new Member();
  User B = new User()

is the object A larger than object B? I know it's an 开发者_如何学JAVAodd question but I believe every intantiation of an object eats memory space..

The size of a class instance is determined by:

The amount of data actually stored in the instance
The padding needed between the values
Some extra internal data used by the memory management

So, typically a class containing a string property needs (on a 32 bit system):

8 bytes for internal data
4 bytes for the string reference
4 bytes of unused space (to get to the minimum 16 bytes that the memory manager can handle)

And typically a class containing an integer property needs:

8 bytes for internal data
4 bytes for the integer value
4 bytes of unused space (to get to the minimum 16 bytes that the memory manager can handle)

As you see, the string and integer properties take up the same space in the class, so in your first example they will use the same amount of memory.

The value of the string property is of course a different matter, as it might point to a string object on the heap, but that is a separate object and not part of the class pointing to it.

For more complicated classes, padding comes into play. A class containing a boolean and a string property would for example use:

8 bytes for internal data
1 byte for the boolean value
3 bytes of padding to get on an even 4-byte boundary
4 bytes for the string reference

Note that these are examples of memory layouts for classes. The exact layout varies depending on the version of the framework, the implementation of the CLR, and whether it's a 32-bit or 64-bit application. As a program can be run on either a 32-bit or 64-bit system, the memory layout is not even known to the compiler, it's decided when the code is JIT:ed before execution.

In general, a class is larger when it has many instance (non-static) fields, regardless of their value; classes have a memory minimum of 12 bytes and fields with reference types are 4 bytes on 32-bit systems and 8 bytes on 64-bit systems. Other fields may be laid out with padding to word boundaries, such that a class with four byte fields actually may occupy four times 4 bytes in memory. But this all depends on the runtime.

Don't forget about the fields that may be hidden in, for example, your automatic property declarations. Since they are backed by a field internally, they'll add to the size of the class:

public string MyProperty
{ get; set; }

Note that the following property has no influence on the class size because it isn't backed by a field:

public bool IsValid
{ get { return true; } }

To get an idea of the in-memory size of a class or struct instance: apply the [StructLayout(LayoutKind.Sequential)] attribute on the class and call Marshal.SizeOf() on the type or instance.

[StructLayout(LayoutKind.Sequential)]
public class MyClass
{
    public int myField0;
    public int myField1;
}

int sizeInBytes = Marshal.SizeOf(typeof(MyClass));

However, because the runtime can layout the class in memory any way it wishes, the actual memory used by an instance may vary unless you apply the StructLayoutAttribute.

While the following article is old (.NET 1.1), the concepts explain clearly what the CLR is doing to allocate memory for objects instantiated in your application; which heaps are they placed in, where their object reference pointers are addressing, etc.

Drill Into .NET Framework Internals to See How the CLR Creates Runtime Objects

You can also check: how-much-memory-instance-of-my-class-uses. There is easy way to test size of object after constructor is called.

There's a project on github called dotnetex that uses some magic and shows the size of a class or object.

Usage is simple:

GCex.SizeOf<Object>();    // size of the type
GCEx.SizeOf(someObject);  // size of the object;

Under the hood it uses some magic.
To count size of a type it casts pointer of method table to internal MethodTableInfo struct and uses it's Size property like this:

public static unsafe Int32 SizeOf<T>()
{
    return ((MethodTableInfo *)(typeof(T).TypeHandle.Value.ToPointer()))->Size;
}

To count size of an object it uses true dark magic that quite hard to get :) Take a look at the code.

When one says class size, I would assume that it means how many members the class has, and how complex the class is.

However, your question is the size of the memory required when we are creating instance of class. We cannot be so sure about exact size, because .Net framework preserves and keeps the underlying memory management away from us (which is a good thing). Even we have the correct size now, the value might be correct forever. Anyway, we can be sure that the following will take some space in the memory: