"Overhead" of Class vs Structure in C#?

I'm doing course 3354 (Implementing System Types and Interfaces in the .NET Framework 2.0) and it is said that for simple classes, with members variables and fun开发者_如何学运维ctions, it is better to use a struct than a class because of overhead.

I have never heard of such a thing, what is the validity of this claim?

I recommend to never use a struct unless you have a very specific use-case in mind and know exactly how the struct will benefit the system.

While C# structs do allow members, they work a good bit different then classes (can't be subtyped, no virtual dispatch, may live entirely on the stack) and the behavior changes depending upon lifting, etc. (Lifting is the process of promoting a value type to the heap -- surprise!)

So, to answer the question: I think one of the biggest misnomers in C# is using structs "for performance". The reason for this is 'overhead' can't be truly measured without seeing how it interacts with the rest of the system and the role, if anything of note, it plays. This requires profiling and can't be summed up with such a trivial statement as "less overhead".

There are some good cases for struct value types -- one example is a composite RGB value stored in an array for an image. This is because the RGB type is small, there can be very many in an image, value types can be packed well in arrays, and may help to keep better memory locality, etc.

You should in general not change a type that should be a class into a struct for performance reasons. Structs and classes have different semantics and are not exactly interchangeable. It is true that structs can sometimes be faster, but they can also sometimes be slower. They behave differently and you should recognize when to use one or the other.

MSDN has a page on choosing between classes and structures.

The summary is:

Do not define a structure unless the type has all of the following characteristics:

• It logically represents a single value, similar to primitive types (integer, double, and so on).
• It has an instance size smaller than 16 bytes.
• It is immutable.
• It will not have to be boxed frequently.

There may occasionally be a case where a type really should be a class but you need it to be a struct for performance reasons. This is rare and you should make sure you know what you are doing before taking this route. It can be especially dangerous if you break the immutability guideline for structs. Mutable structs can behave in ways that most programmers don't expect.

When C# was in beta, I was treated to a demonstration of the difference between class and struct. The developers had built a Mandelbrot set viewer, which grinds a lot of complex numbers to accomplish its result. IN the first instance, they ran the code with complex numbers represented as a class with a Real and Imaginary field. Then, they changed the word class to struct and recompiled. The difference in performance was huge.

Not having to allocate heap objects nor having to garbage collect them, in this scenario, was what made the difference. Depending on how many objects you have, the difference may be more or less spectacular. Before you start tweaking, measure your performance and only then make a decision as to go with the value type.

You're going to use a class about 95% of the time. Value type semantics end up biting you in the ass more often than not down the road.

If however, you're going with a struct, make sure that it's immutable.

In C#, classes and structs are completely different beasts. The syntax is nearly identical for the two but the behavior is completely different (reference vs. value). An individual instance of a struct will use less memory than the equivalent class but once you start building collections or passing them around, the value type semantics will kill you in terms of performance (and possibly memory consumption depending on what you're doing) unless the data in the struct is very small. I don't know what the hard number is but we're talking about on the order of 8 bytes or less.

It can also hurt in terms of maintainability and readability because the two look so similar but behave so differently.

One rule of thumb you can follow is to ask yourself whether or not what you are trying to do is like System.Date If it's not, then you should really really question your decision to use structs.

struct is a value type and class is a reference one. this could be one of the reason.

For simple types where you will have many of them, don't require inheritance, and are a good candidate for being immutable, structs are a good choice. Examples of this are Point, Rectangle, Decimal, and DateTime.

If you will not have many of them, the overhead is irrelevant and it shouldn't factor into your decision. If you will ever need to derive from it (or make it a derived type), it has to be a class. If the item cannot be immutable, struct is not a good candidate because mutating one instance won't change any copies of it.

I believe the most commonly quoted break-even point is around 12 bytes of data in your struct. So for example, 3 integers. The difference between value type and reference type is much more fundamental though, and you should make your choice based on that for types with few members.

If something is big, then class :)

Structs are value types and classes are reference types. So, if you're going to pass around references, classes can be better performance-wise since you are copying an address rather than the whole structure. However, if you are going to instantiate and reference these objects a large number of times, structs will be much better-performing because they are allocated on the stack. So, structs can be better for numerous objects where performance is important or in small objects where value-type semantics are desirable. Structs also have no default constructor. They do inherit from Object, but otherwise they are inheritance-free.

There's no need to allocate/deallocate structs.