Does using in ever result in worse performance for structs?

[HopefulFrog]

Specifically for structs with multiple fields. I ask because I'm working on a game and I'm passing around a lot of Rectangles, Points, Colors and whatnot. Just wondering if there's ever cases where it would actually provide better performance to pass copies of those structs rather than passing by reference.

[CyrusNajmabadi]

This is not a csharplang question. This is a perf question which will be affected by many factors (including basic things like what runtime/not you're using). The only way to answer this is to measure.

Note: in practice 'in' can absolutely make things slower as it may just be faster to copy something and use it directly versus going through a reference. But it will depend on many factors, and profiling it's the only way to answer.

[HopefulFrog]

Well that's unfortunate. I had thought the primary motivation behind introducing in as a language feature was for performance considerations. According to Microsoft Docs:

Defining methods using in parameters is a potential performance optimization. Some struct type arguments may be large in size, and when methods are called in tight loops or critical code paths, the cost of copying those structures is critical. Methods declare in parameters to specify that arguments may be passed by reference safely because the called method does not modify the state of that argument. Passing those arguments by reference avoids the (potentially) expensive copy.

But I guess it's not as simple as it just always being better for performance with larger structs. It does say "potential performance optimization."

[BreyerW]

If struct is bigger than pointer (so 32 bits for 32bit apps and 64 for 64bit apps then passing by ref or in theoretically should almost always win since passing by ref requires creating pointer. But if struct is only slighty larger then any perf gains will drown in background noise like cpu instabilities and other factors so theres not much point unless ur code is going to be executed billions of times. For this reason passing by ref makes sense mostly for larger structs like most variations of matrix and larger

And keep in mind the gotcha with in: if you call a member NOT marked readonly compiler will silently insert defensive copy for each call which can absolutely murder your perf

[tannergooding]

Noting that its generally said to be 2 * sizeof(void*), as many platforms (particularly Unix) will allow passing values in 2x registers.

HFAs, HVAs, and more can also be passed in 1-4 registers.

Inlining also can come into play, as passing byref can hinder optimizations once inlining comes in (if the original value is a local in the caller).

[HopefulFrog]

And keep in mind the gotcha with in: if you call a member NOT marked readonly compiler will silently insert defensive copy for each call which can absolutely murder your perf

Yeah, I read about that on the Microsoft Docs website, and I quickly removed all in references from my project after that. The structs I was passing around with in are mostly all mutable. (Gasp!)

I guess ref wouldn't have that problem, but I think I'll just stick to passing by value.

[tannergooding]

There are many cases, even with multiple fields, where in can perform worse. This becomes particularly prevalent when considering Windows vs Linux vs MacOS and x86 vs x64 vs Arm32 vs Arm64.

Typically:

• If its 1 runtime primitive, you don't use in
• If its 1-4 floating-point fields of the same size, you don't use in
• If its 1-4 vector fields of the same size, you don't use in
• If its 2 integer fields of the same size, you don't use in
• If the function is small enough that inlining is expected, you don't use in
• If its only integer fields and the size is less than or equal to sizeof(void*) * 2, you may not want to use in

There is various nuance and other considerations here. The number of parameters you're passing, the platform or architecture you're targeting, the calling convention of the method, and more can all come into play and drive things in a different direction.

[HopefulFrog]

Sounds like I should mostly stick to just passing by value, then. Thanks!