Question

It maybe unclear for me but, when I read the msdn doc and I try to understand deeply Struct behaviour.

From msdn

Dealing with Stack :

This will yield performance gains.

and :

Whenever you have a need for a type that will be used often and is
mostly just a piece of data, structs might be a good option.

I don’t understand because, I guess when I pass a Struct in parameter of a method the “copy value” process must be slower than “copy reference” process?

Answer 1

The cost of passing a struct is proportional to its size. If the struct is smaller than a reference or the same size as a reference then passing its value will have the same cost as passing a reference.

If not, then you are correct; copying the struct might be more expensive than copying the reference. That’s why the design guidelines say to keep a struct small.

(Note that when you call a method on a struct, the “this” is actually passed as a reference to the variable that contains the struct value; that’s how you can write a mutable struct.)

There are potential performance gains when using structs, but as you correctly point out, there are potential performance losses as well. Structs are cheap (in both memory and time) to allocate and cheap to deallocate (in time), and cheap to copy if they are small. References are slightly more expensive in both memory and time to allocate, more expensive to deallocate, and cheap to copy. If you have a large number of small structs — say, a million Point structs — then it will be cheaper to allocate and deallocate an array with a million structs in it than an array with a million references to a million instances of a Point class.

But if the struct is big, then all that additional copying might be more expensive than the benefit you get from the more efficient allocation and deallocation. You have to look at the whole picture when doing performance analysis; don’t make the “struct vs class” decision on the basis of performance without empirical data to back up that decision.

There is much misinformation on the internet, in our own documentation, and in many books, about how memory management works behind the scenes in C#. If you are interested in learning what is myth and what is reality, I recommend reading my series of articles on the subject. Start from the bottom:

http://blogs.msdn.com/b/ericlippert/archive/tags/memory+management/