What does large actually mean in the context of structs and in parameter modifier?

[voroninp]

I see that ISpanParsable interface defines methods which accept ReadOnlySpan without in modifier.

Span itself contains two fields: reference and length. So, its size is obviously larger than the size of the reference. And yet designers did not think applying in modifier was justified: ReadOnlySpan is not "large enough".

Is there an objective criterion for the size of readonly struct when using in is a win?

[tannergooding]

It depends on several bits of context. This includes, but isn't limited to:

• size of the method
• whether the method will be inlined
• how the parameters are accessed/used
• ABI of the underlying target platform
• Layout of the struct in question
• etc

Some platforms allow structs that are less than or equal to 2 pointers in length to be passed in multiple registers.
Some platforms allow structs that contain 1-4 floating-point or 1-4 SIMD types to be passed in multiple registers.
Some platforms allow structs with many fields that are less than or equal to a pointer in length to be passed in a single register.

All of this nuance basically means there is no "correct" answer and context has to be taken into account. A good general rule of thumb for perf oriented code is that anything that is 16-bytes or less should be passed by value, if it's more than that consider using in. Of course specialized scenarios involving vectorization/simd or platform specific targets may cause this to differ.

The Framework Design Guidelines essentially outlines that structs should:

• logically represent a single value
• be less than or equal to 24 bytes
• immutable
• not require frequent boxing

There's then some annotations from different team members discussing some of the points I gave above. Of course, internal or domain specific types can break these guidelines; but they do layout some solid foundations around when/why structs should or should not be used.

Structs that are too large or have a layout that doesn't allow them to be passed in register for a given platform are ultimately still passed by reference. The difference between T value and in T value in that context is whether that is implicit and done via a "shadow copy" or explicit. Explicit can remove this hidden copy, but then forces explicit aliasing which the JIT cannot optimize around without inlining. That can prevent other optimizations such as promotion, enregistration, and more.

So ultimately it really depends and requires you to profile, measure, and consider the contract for the type and how its intended to be used. Both at the current point in time and in the theoretical future for any changes that might happen.