So are properties inlined, in unity in a final build I mean.
Mono is notoriously bad at inlining. If you look at the JITed code almost nothing is inlined
1 Like
Unity builds completely differently for every target and ABI, such as Mono, IL2CPP, ARM, ARM64, x86, etc.
Before you waste too much of your life wondering about inlining, be sure you have a problem first, or you’ll just be wrecking your codebase for absolutely no gain whatsoever.
DO NOT OPTIMIZE “JUST BECAUSE…” If you don’t have a problem, DO NOT OPTIMIZE!
If you DO have a problem, there is only ONE way to find out. Always start by using the profiler:
Window → Analysis → Profiler
Failure to use the profiler first means you’re just guessing, making a mess of your code for no good reason.
Not only that but performance on platform A will likely be completely different than platform B. Test on the platform(s) that you care about, and test to the extent that it is worth your effort, and no more.
https://discussions.unity.com/t/841163/2
Remember that optimized code is ALWAYS harder to work with and more brittle, making subsequent feature development difficult or impossible, or incurring massive technical debt on future development.
Notes on optimizing UnityEngine.UI setups:
https://discussions.unity.com/t/846847/2
At a minimum you want to clearly understand what performance issues you are having:
- running too slowly?
- loading too slowly?
- using too much runtime memory?
- final bundle too large?
- too much network traffic?
- something else?
If you are unable to engage the profiler, then your next solution is gross guessing changes, such as “reimport all textures as 32x32 tiny textures” or “replace some complex 3D objects with cubes/capsules” to try and figure out what is bogging you down.
Each experiment you do may give you intel about what is causing the performance issue that you identified. More importantly let you eliminate candidates for optimization. For instance if you swap out your biggest textures with 32x32 stamps and you STILL have a problem, you may be able to eliminate textures as an issue and move onto something else.
This sort of speculative optimization assumes you’re properly using source control so it takes one click to revert to the way your project was before if there is no improvement, while carefully making notes about what you have tried and more importantly what results it has had.
2 Likes
I don’t have performance problems, I’m just curious. I’m talking about Il2cpp. Also its good to know for intensive loops. I usually try not to micro optimize my code but there are parts where it is necessary, so I want to keep this in mind.
Usually I try to start with a good design first, I mean having a good architecture can save you a lot of time refactoring your code.
Following the singleton pattern I usually try to make GameManager etc… but also some performance Managers like Object pools. Having a manager to reuse arrays and objects from the start will help a lot in the future. I’ve found that I always get problems with allocations so a clean Object pool class remedies that.
Always catch the lowest hanging fruit by profiling.
1 Like
For IL2CPP it probably will inline all auto properties. I’ve checked output C++ code for my game and here you can see there’s FORCE_INLINE tag on the method
I’m assuming non-auto properties are treated as just methods and inlining rules will be the same as for any other method, meaning if it’s not big, then it will get inlined.
1 Like
According to the docs, when you set code stripping to “high” simple properties get inlined. I never actually verified to see if this actually happens, however.
1 Like
That is good news because simple auto properties are very good to hide fields from other classes. I never used complex logic in properties anyways.