How to check the number of bytes consumed by my Structure?

Question

Hi, If I am creating realtively large structure how can I calculate the bytes it occupies in memory. We can do it manually , but if the struct is large enough then how to do it? Is there some code chunk or Application?

Answer 1

You can use the sizeof operator.

But I think best way is to use the managed SizeOf function.

A good way to use this is to have a generic method or extension method like these:

static class Test
{
    static void Main()
    {
        //This will return the memory usage size for type Int32:
        int size = SizeOf<Int32>();

        //This will return the memory usage size of the variable 'size':
        //Both lines are basically equal, the first one makes use of ex. methods
        size = size.GetSize();
        size = GetSize(size);
    }

    public static int SizeOf<T>()
    {
        return System.Runtime.InteropServices.Marshal.SizeOf(typeof(T));
    }

    public static int GetSize(this object obj)
    {
        return System.Runtime.InteropServices.Marshal.SizeOf(obj);
    }
}

Answer 2

A struct should have a maximum size of 16 bytes. If your struct is larger than that then you should use a class.

Answer 3

You can use System.Runtime.InteropServices.Marshal.SizeOf() to get the size in bytes as well.

Answer 4

You can either use the sizeof() keyword for user-defined structs that do not contain any fields or properties that are reference types, or use the Marshal.SizeOf(Type) or Marshal.SizeOf(object) to obtain the unmanaged size of a type or a struct that has a sequential or explicit layout.

Answer 5

you want to use System.Runtime.InteropServices.Marshal.SizeOf()

struct s
    {
        public Int64 i;

     }

public static void Main()
        {
            s s1;
            s1.i = 10;

            var s = System.Runtime.InteropServices.Marshal.SizeOf(s1);
        }

Answer 6

Structs have been troublesome beasts in computer engineering for a very long time. Their memory layout is very hardware dependent. To make them efficient, their members must be aligned so the CPU can read and write their values quickly without having to multiplex the bytes to fit the memory bus width. Every compiler has its own strategy of packing the members, often directed by, for example, the #pragma pack directive in a C or C++ program.

Which is okay, but rather a problem in interop scenarios. Where one chunk of code may make different assumptions about the structure layout than another chunk, compiled by a different compiler. You can see this back in COM, .NET's grandfather solution to interop programming. COM has very poor support for handling structs. It doesn't support them as a native automation type but has a workaround through the IRecordInfo interface. Which lets a program discover the memory layout at runtime through an explicit declaration of the structure in a type library. Which works okay, but is quite inefficient.

The .NET designers made a very courageous, and correct, decision to solve this problem. They made the memory layout of a struct completely undiscoverable. There is no documented way to retrieve the offset of a member. And by extension, no way to discover the size of the struct. Everybody's favorite answer, use Marshal.SizeOf() is not in fact the solution. That returns the size of struct after it is marshaled, the size you'd need to pass to, say, Marshal.AllocCoTaskMem() before you call Marshal.StructureToPtr. That arranges and aligns the struct members according to the [StructLayout] attribute that's associated with the struct. Note that this attribute isn't required for structs (like it is for classes), the runtime implements a default one which uses the declared order for the members.

One very nice side-effect of the layout being undiscoverable is that the CLR can play tricks with it. When packing the members of the struct and aligning them, the layout can get holes that don't store any data. Called padding bytes. Given that the layout is undiscoverable, the CLR can actually use the padding. It moves a member if it is small enough to fit such a hole. You'll now actually get a struct whose size is smaller than what would normally be required given the declared structure layout. And, notably, Marshal.SizeOf() will return the wrong value for the structure size, it returns a value that's too large.

Long story short, there's no general way to get an accurate value for the structure size programmatically. The best thing to do is to just not ask the question. Marshal.SizeOf() will give you a guesstimate, assuming the structure is blittable. If you need an accurate value for some reason then you could look at the generated machine code of a method that declares a local variable of the structure type and compare it to the same method without that local variable. You'll see the difference in the stack pointer adjustment, the "sub esp, xxx" instruction at the top of the method. Of course, it will be architecture dependent, you'll typically get a larger structure in 64-bit mode.