I currently add a lot of these attributes to my methods because they’re really rather small. Like this one:
[MethodImpl(MethodImplOptions.AggressiveInlining)]
public float3 CalculateCentroid() => _calculate.Centroid(_data);
I haven’t measured it (I worry a simple test could be misleading) and I’m not sure what to look for in Burst Inspector so I thought I’ll just ask: is this attribute required for Burst to inline methods? Or does Burst just do whatever it thinks is right and we can just stop littering this crazy-long attribute throughout our code?
Also, specifically for code compiled in and for the editor, is inlining supported?
Why I’m asking is less about performance but code quality. This attribute really adds to noise and I’m tempted to just throw it all away because it starts to get really ugly real fast:
The manual does not contain the phrase “inlin” at all. On the forum are various threads saying either this or that, but these are old posts, like 2-4 years ago.
It biases Burst to be more aggressive, but Burst is already fairly aggressive so it usually has no effect. It matters more for when the code is executed outside of Burst.
The general consensus, even though most articles are several years old, seems to be to AVOID the AggressiveInlining attribute. In some cases it can even be detrimental but in most cases, like you said, it has no effect because Burst is inlining anyway.
Conclusion: it can’t hurt to add the attribute to some methods called repeatedly in critical loops while testing performance. But other than that just trust Burst to do the right thing.
It is my experience that how aggressive Burst automatically inlines changed with Burst versions. It became less aggressive at some point. But this only affected large methods that I wanted to be inlined. Small methods have always been automatically inlined. I discovered this because I search for unwanted call instructions in Burst’s generated code.
My current approach is to not add the attribute but check whether call instructions are generated. If so, add the attribute to the large methods that do not get inlined automatically.
1 liners are 100% inlined. No need for the tag.
I’ve never witnessed any deviation from it. I’m not sure about the breakpoint of inlining or not. Mix of instruction count, method stackalloc and probably other stuff. Burst is highly aggressive with inlining so it’s actually very rare you ever need it.
It’s still a good habit, to explicitly inline, just to make it clear. But again, for one liners, save the lines of code.
