Question Can I use OnTriggerStay safely without performance issues?

Hi all,
Because I am afraid of OnTriggerStay's possible performance problems (checking the trigger situation in every frame) I decided not to use it and instead try to do things with OnTeriggerEnter (as much as it helps)
Am I wrong?

 

Well it only triggers once per physics update, not per frame, as the documentation states.

And how performant or non-performant it is entirely depends on what you're doing in each step. If you have a performance issue, break out the profiler. Don't speculate.

 

fixedupdate also means per-frame.

 

Um... no it doesn't? Maybe read the docs: https://docs.unity3d.com/ScriptReference/MonoBehaviour.FixedUpdate.html

It's called per your Fixed Timestep interval in your project settings. This can be more or less than the amount of frames per second, but remains relatively independent of your frame rate.

So once again, use the profiler to determine your performance issues should you have one.

 

no it is. Because my message is about "Performance concerns" and 0.02 timestep means 50 frame/persec. try to think deep and understand what others mean.

 

That's still not per frame; you could be at 30 fps and be getting nearly double the fixed updates per frame. Thus, not per frame, but per physics update. It's an important distinction to make.

Your misunderstanding of terminology and how Unity works aside, the answer is always "it depends" and can rarely be answered in a vacuum. Everything has the potential to be a performance issue if abused.

So I reiterate.

Stop speculating, and use the profiler.

 

Your obsession with the concepts instead of answering the question has killed a significant portion of my precious time. let's stop arguing now and get down to business
.
.

 

I've answered it three times over already.

 

Spiney has been very patient and answered your question multiple times in this topic. The simple answer is, profile and test it yourself. This is not really something anyone can answer for you as we have no idea of what it is that you are going to be putting into your ontriggerstay method so we can't tell you if it is going to be overloaded. Why don't you start using it and then only change if it starts to be a problem?

 

Your concept of a "frame" is simply wrong.

I suggest that instead of pouting about your precious time and trying to convince Spiney to adopt your incorrect "frame" terminology, you take the time to understand what a "frame" means in Unity and how a "frame" means ABSOLUTELY NOTHING to FixedUpdate().

Documentation to back this up:

From this diagram:



Here is some timing diagram help:

https://docs.unity3d.com/Manual/ExecutionOrder.html

Two good discussions on Update() vs FixedUpdate() timing:

https://jacksondunstan.com/articles/4824

https://johnaustin.io/articles/2019/fix-your-unity-timestep

As to your original question about performance, that has not changed since the last time I posted it for you before. It is also unlikely to change in the future either, so it won't be useful for you to keep asking about optimization.

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://forum.unity.com/threads/is-...ng-square-roots-in-2021.1111063/#post-7148770

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://forum.unity.com/threads/how...form-data-into-an-array.1134520/#post-7289413

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.

 

you are correct, ontriggerenter will only trigger once so its much better performance than ontriggerstay no matter how you slice it. you commited the grave sin of asking about future performance problems on these forums though may god save your soul