C#. Struct design. Why 16 byte is recommended size?

Question

I read Cwalina book (recommendations on development and design of .NET apps).

He says that good designed struct has to be less than 16 bytes in size (for performance purpose).

My questions is - why exactly is this?

And (more important) can I have larger struct with same efficiency if I run my .NET 3.5 (soon to be .NET 4.0) 64-bit application on i7 under Win7 x64 (is this limitation CPU / OS based)?

Just to stress again - I need as efficient struct as it is possible. I try to keep it in stack all the time, the application is heavily multi-threaded and runs on sub-millisecond intervals, the current size of the struct is 64 byte.

Answer 1

• Larger struct is not as efficient, but then.... if you HAVE more data, you have it. No sense talking about efficiency there.

• 64 bytes shuold be ok.

• The main reason possibly is copy operations.... which get IIRC slower if the struct is larger. And it must be copied around quite a lot.

I would normally advice into using a class here ;) But without knowing the content of the struct, it is a little tricky.

Answer 2

You're misquoting the book (at least the 2nd edition). Jeffrey Richter states value types can be more than 16 bytes if:

You don't intend to pass them to other methods or copy them to and from a collection class.

Additionally Eric Gunnerson adds (regarding the 16 byte limit)

Use this guideline as a trigger to do more investigation.

It is simply not true that a struct "has to be less than 16 bytes in size". It all depends on usage.

If you are creating the struct and also consuming it and are worried about performance then use a profiler comparing a struct vs class to see which works best for you.

Answer 3

Only you know how your structs are being used in your program. But if nothing else, you can always test it for yourself. For instance, if it's frequently passed to other functions, the following may illuminate you:

class MainClass
{
    static void Main()
    {
        Struct64 s1 = new Struct64();
        Class64 c1 = new Class64();
        DoStuff(s1);
        DoStuff(c1);
        Stopwatch sw = new Stopwatch();
        sw.Start();
        for (int i = 0; i < 10000; i++)
        {
            s1 = DoStuff(s1);
        }
        sw.Stop();
        Console.WriteLine("Struct {0}", sw.ElapsedTicks);
        sw.Reset();

        sw.Start();
        for (int i = 0; i < 10000; i++)
        {
            c1 = DoStuff(c1);
        }
        sw.Stop();
        Console.WriteLine("Class {0}", sw.ElapsedTicks);
        sw.Reset();

        Console.ReadLine();
    }
}

with:

public class Class64
{
    public long l1;
    public long l2;
    public long l3;
    public long l4;
    public long l5;
    public long l6;
    public long l7;
    public long l8;
}
public struct Struct64
{
    public long l1;
    public long l2;
    public long l3;
    public long l4;
    public long l5;
    public long l6;
    public long l7;
    public long l8;
}

Try this sort of thing with representative structs/classes, and see what results you get. (On my machine, above test, the class seems ~3 times faster)

Answer 4

I think another key point is that if you have a list with a million structs, that is still only one memory allocation on the heap, while a list with a million classes in it is going to have about a million separate heap objects. The garbage collection load is something quite different in both cases. From this point of view, the struct may come out ahead.

Answer 5

One of the things i learnt while assembly language programming is that you align your structs (and other data) on 8 or 16 byte boundaries (there is actually a preprocessor command for it in MASM). The reason for this is considerably faster memory access when storing or moving things around in memory. Keeping your structs under 16 bytes in size would ensure that this memory alignment could be done successfully because nothing would cross the alignment boundaries.

However i would expect this sort of thing to be largely hidden from you when using the .Net framework. If your structs were bigger than 16 bytes them i would expect the framework (or JIT compiler) to align your data on 32 byte boundaries, and so on. It would be interesting to see some validation of the comments in those books, and see what the difference in speed is.