Question different between "in" and "RefRO" keyword ?

i am confuse about this, is "RefRO" better than "In" about Performance ?

 

Should be none in theory. Both should codegen into read only variable.
RefRO is more verbose in a way it shows more intent that variable is modified externally and read only.

 

With Burst, they are usually the same. But in some cases, RefRO has extra scaffolding that can trip Burst up from making a good optimization. Outside of Burst, you'd have to profile. There are a lot of speculations floating around.

 

I think the primary use case of RefRO is

Code (CSharp):

1. foreach(var component in SystemAPI.Query<RefRO<MyComponent>>())
2. {
3.  
4. }

where you can't use 'in'

In IJobEntity it probably makes no difference. They'll likely both fall into the same traps of make defensive copies of components.

 

That's maybe true if you aren't using Burst, but then that begs the question, why aren't you using Burst?

With Burst, defensive copies on "in" parameters never happen. If your intent is to use Burst, you should use "in" because it improves Burst's ability to optimize. Sometimes that doesn't matter because Burst will see the optimization anyway, but for particularly complex code it does make a difference. In one project that is heavily bottlenecked by physics and spatial queries, I changed one argument to use "in" and saw a 20% improvement in frame times.

I've been seeing people lately ruin their APIs thinking that all "in" parameters are bad. I guess if you expect that the code will be called from non-Burst it makes sense, especially for internal logic. But if you expect code to be Burst-compiled, the Burst team literally made a blog post telling people to seriously consider using "in" parameters because it improves their compiler's ability to optimize.

Sorry for the rant, but this one has been really bothering me lately.

 

this is true !!! i was thinking about this, because in programing there is cost of copying data.So i guess The Burst Complie makes "in" have better performance. thanks.

 

I know this was more of a general rant but just be be clear, I'm a fan of `in` & `readonly ref` and use them throughout my libraries.
I think switching to ref to avoid defensive copies is weird as it doesn't matter most of the time and as you say ruins your API.

I was just pointing out if you were someone who did care about this with 'in', then RefRO doesn't solve it so there's no benefit of switching your IJobEntity executes.

 

Wherever possible, I almost always only make components readonly structs, so there are no longer any defense copies (outside burst). If components only have a few fields, that shouldn't be a problem either.
If I remember correctly, RefRO itself are readonly scripts that contain a pointer to the component, so there is no defense copy here either.

 

Isn't the Execute method inlined when the code is compiled with Burst? In that case does passing by value/reference matter? If it matters at what struct size does it start making a difference? If anyone has profiled something similar to this I'd like to know your thoughts.