👋 Introduction

One of the inevitable cases of programming is creating POCOs, DTOs, Value Objects, objects whose (generally) sole purpose is to hold data together so that it can be passed as a single argument to a method. Most developers automatically define these as classes. Let's see the difference between using classes vs. structs for data.

⚖️ Performance Pros & Cons

Classes

✔️ Has inheritance
✔️ Always passes by ref >> better performance when class is bigger.
⚠️ Calling methods on it is a callvirt (except when sealed).
❌ Cost of allocation

Structs

✔️ No allocations
✔️ Calling methods on it does not involve callvirt.
⚠️ Must define explicitly when passing by ref is required using the ref or in keywords. It is also passed by ref when compiler can optimize it to.
❌ No inheritance

⏱️ Performance

Let's start with the obvious: classes require allocation because they're placed on the heap, whereas structs doesn't require one because they're placed on the stack. Allocating in the heap is costly, but how costly it is exactly? The difficulty of answering it comes from the fact that allocation itself is just one part of the equation, one should also measure GC impact. Now, I'm not saying it's impossible to benchmark it, but creating a server environment with dummy endpoints and then calling them is still too "artifical" for a test like that, so I'm gonna take the path of the least resistance here, and just make some dummy methods and Benchmark.NET them, because one thing is sure: the mroe you allocate the more resource you need to garbage collect them.

Methodology

Download the Sample Code

• Inlining must be disabled because I also want to show the cost of copying structs as parameters.
• I need to call the method twice sequentially, so that the compiler won't passes a simple struct by reference just because it knows it can do that, because the struct won't be used after the method call.
• The triple arguments (i.e. triple allocations) are needed to show a more accurate difference. It's an analogy for unrolling instead of looping (where you don't want to include the overhead of looping in your benchmark, here I want to minimize the overhead of calling those dummy functions twice, and want to emphasize the allocation and passing of arguments part):

Benchmark cases

• Using a class
• Using a struct
• Using a struct and passing it as byref.
• Using a readonly struct.
• Using a readonly struct and passing it as an interface.
• Using a class and passing it as an interface.
• Using a class from an object pool (no allocation, but cost of renting from the pool. I omitted returning, because - spoiler alert - even the renting part is pretty costly.)

Results

BenchmarkDotNet=v0.13.2, OS=Windows 10 (10.0.19045.2728)
Intel Core i7-3770S CPU 3.10GHz (Ivy Bridge), 1 CPU, 8 logical and 4 physical cores
.NET SDK=7.0.201
[Host]     : .NET 7.0.4 (7.0.423.11508), X64 RyuJIT AVX
DefaultJob : .NET 7.0.4 (7.0.423.11508), X64 RyuJIT AVX

BenchmarkDotNet=v0.13.5, OS=Windows 11 (10.0.22621.1555/22H2/2022Update/SunValley2)
Intel Core i5-10210U CPU 1.60GHz, 1 CPU, 8 logical and 4 physical cores
.NET SDK=8.0.100-preview.2.23157.25
[Host]     : .NET 7.0.5 (7.0.523.17405), X64 RyuJIT AVX2
DefaultJob : .NET 7.0.5 (7.0.523.17405), X64 RyuJIT AVX2

Observations & Comments

• ReadOnly Structs: I figured the compiler would optimize this and would pass it by ref, since it is readonly, meaning there's no purpose in copying it. But it's probably the same logic as if the struct would be a readonly field itself in which case the compiler creates defensive copies to make sure the struct remains untouched.
• Copying of structs: According to my benchmarks on .NET7 it seems that after 64bytes the compiler stops inlining the method that copies the struct which results in additional call operations that suddenly makes it worse comparing to classes. It must be checked on .NET8 whether the implementation of 512bit vectors might cause inlining at higher sizes only.
• Structs implementing interfaces: Structs implementing interfaces causes GC allocation (due to boxing when passed as interfaces) which makes them your worst possible option. You can see the allocation is twice as much as in the case of classes. This is due to the number of arguments (6), because for all the arguments to be able to pass it, they have to be boxed, which is 6 boxing, which is 6 allocations. In the cases of classes, there are 3 allocations only.
  • one can circumvent this by passing them as generic params which have interface constraints.
• StackOverflowException: Large structs are always risky due to limited stack space.

The struct, the readonly, and the in keywords

Defensive copy may happen when you defined your struct, or the field you assigned it to as readonly, or when your argument has the in modifier but you pass it without the in modifier. It happens, because the compiler would like to make sure that you're original struct remains untouched, and it achieves this by giving you a copy of the struct each time you access it so that your original one cannot be modified in any way. The good news is, that this behaviour became much more consistent and predictable in .NET Core (don't know exactly when). In .NET 7, the compiler creates defensive copies every time when the struct is passed byval, and skips creating it when passed byref.

It's worth noting that there are cases when you don't need to use the in or ref keyword to pass the struct by reference. One example is the one I avoided deliberately in the benchmarks (because I wanted the JIT to create copies to benchmark copy time):

1. Have a struct by value (so create it locally, or have it as a byval argument)
2. Calling a method with that struct as an argument
3. Do nothing with the struct

Actually large structs always get passed by ref (ref relative to the stack or the stack base pointer), the question is: will the compiler create a defensive copy? In this case, it obviously won't do such a thing, because a copy would only be needed for a second usage of the struct, but there's only a single usage, the method call, for which the compiler passes the newly created struct by ref.

📋 Summary

Performance Table

Other disadvantages/restrictions of structs

When passing it by ref (using the in or ref keyword):
❌ Cannot be used in async methods
❌ Cannot be used in iterator methods (methods that contains the yield statement)
❌ Cannot be used in the first parameter of an extension method when the struct is to be extended is defined as a generic type.

When using with generic typed APIs:
❌ Most of the time there is a reference-only type restriction defined
❌ Even when there's no reference-only restriction, the API might simply not work with value types (it's essentially a bug, devs tend to forget specifying the reference-only type restriction)

Takeaway

All in all, it's probably a good rule of thumb to always use, or at least strive to use structs when you want to define a data structure. With structs you get greater allocation performance, and won't put any pressure on the GC.