I'm curious why MemoryOwner<T> is implemented as a class instead of a struct.

[RobbyScherpereel]

I believe the title is clear. But a bit of context.

While refactoring some code to optimise it's memory usage, and without knowing I was actually creating a similar implementation of MemoryOwner when a colleague told me my code resembled a lot to what MemoryOwner has his purpose, providing a pooled byte[] with a specific lenght.

While performing some benchmarks in order to see which way to go forward, I could see MemoryOwner taking more memory than my implementation, which made me have a look on why this was the case.

I could see MemoryOwner is implemented as a class, while I had the idea to implement it as a struct instead.
After changing my implementation to a class (BuilderWithPooledRequestClassSetup in the benchmark), I could indeed see similar behaviour.

I am now wondering why this is the case and I also what potential pitfalls I have to take into consideration should I proceed with my struct implementation instead?

Method	Mean	Error	StdDev	Median	Gen0	Allocated
OldRequestSetup	247.1 ns	4.99 ns	7.46 ns	245.9 ns	0.1721	1080 B
RequestBuilderSetup	398.4 ns	4.45 ns	3.47 ns	399.7 ns	0.0420	264 B
BetterRequestBuilderSetup	374.7 ns	7.20 ns	15.80 ns	368.8 ns	-	-
BuilderWithMemoryOwnerSetup	637.0 ns	11.69 ns	23.08 ns	631.7 ns	0.0696	440 B
BuilderWithMemoryOwnerNoClearSetup	587.1 ns	11.15 ns	12.84 ns	587.2 ns	0.0696	440 B
BuilderWithSpanOwnerSetup	634.9 ns	11.73 ns	10.97 ns	633.6 ns	-	-
BuilderWithPooledRequestNewOtherMemoryLogicSetup	641.7 ns	11.93 ns	24.09 ns	635.3 ns	-	-
BuilderWithPooledRequestNewOtherSpanLogicSetup	615.0 ns	12.25 ns	12.03 ns	612.4 ns	-	-
BuilderWithPooledRequestClassSetup	740.4 ns	11.58 ns	10.26 ns	741.1 ns	0.0696	440 B

[bzd3y]

I'm not an author/contributor of this library, so I don't know the answer for sure. It could just be something like avoiding premature optimization (although this is a "HighPerformance" library) or it could just be "wrong".

With that being said, there are probably good reasons for it. The guidance (i.e. rules that are broken all the time) I have always seen for deciding a struct vs. class dilemma is something like the following:

Use a struct if (enough of?) the following are true:

1. The size of the type is 16 bytes or less. Above that, a class is usually more performant.
2. The type is not going to be boxed/unboxed frequently. If it is, then it might as well be a class.
3. The type represents a single/primitive value. Obviously it can have fields, but the idea is that it ultimately represents a single value.
4. It is immutable.

I usually see those 4. Here's an example I found that references essentially the same guidance: https://stackoverflow.com/questions/521298/when-should-i-use-a-struct-rather-than-a-class-in-c

It seems like there should be a 5th, that is kind of implied by those 4, but worth pointing out, which is the semantics you want. For example, do you want it to be passed by value or reference?

Now, I'm not familiar with your implementation and only somewhat familiar with the implementation in this library.

Using Unsafe.SizeOf<>() on a struct with the same shape (as far I could tell) as MemoryOwner<> from this library returns 24 bytes. So it is over the 16. It has two "extra" int fields that your implementation might not have.

But, even so, I don't think most of the other things in the guidance list apply to the concept of a "memory owner". A "memory owner" doesn't represent any kind of single or primitive value. And it doesn't seem like it is/could be immutable (conceptually, at least). And I would guess it is either going to get copied pretty frequently or boxed/unboxed pretty frequently.

As for your benchmark results, I'm not sure you should be surprised that the class uses more memory. There is more overhead to classes. But that doesn't mean it is worse. Passing around an 8-byte integer (that is a pointer to a "larger" type) instead of copying something like 24-bytes every time could easily be more performant.

And it depends on what your benchmark is doing/testing. Are you just instantiating a bunch of instances of your implementation and MemoryOwner<> and doing stuff with them? Because I think you'd need to make sure you are doing a test where struct/class memory semantics would be significant, like passing them to methods. And if you are doing that, are you doing it with something like ref? If you are using ref then you're probably getting the benefit of structs and classes.

Two final things:

1. I think the 16 bytes is just a value that was selected to choose some kind of reasonable cut-off. It's possible that something like 24-bytes is still close enough that it would not suffer from being a "large" struct.
2. If I remember correctly, the struct/class keywords don't actually guarantee that the type will be stored on the stack vs the heap respectively, and the compiler/runtime optimizes that some.