More efficient if statement when only fired once in the game

Question

Say I want an if statement that will only fire once each game.
It seems like a waste of effort for me to let the cpu ever check the validity of that condition again once this has happened. Is there a way to somehow not have this checking ever again? It mind not result in any significant performance gain at all. But I'm just curious.

I would like a generic solution that's why I keep it so vague, because I run in these kinds of situations quite often.

Pseudocode:

if(CoinCollected && !CoinCollectedBefore)
{
  //Do stuff   
}

You can [edit] your post to include more information about this `if` block and what it does. With the information at hand, it is very hard to determine what kind of solutions are feasible. What condition is checked? What, if any, properties are modified? etc. — Arc676, Dec 22 '16 at 15:26
Step away from `if()`s altogether in your main application logic and use events or messages. Say, a `CoinCollected` event, which is handled by the relevant event handler(s). The handler itself checks whether the event is relevant for its current state, and optionally updates its state accordingly. When certain conditions are met, the handler itself can emit a new event (e.g. `FirstCoinCollected`). You can run the event handlers on a separate thread, for example, but you'll have to keep monitoring whether the handlers can keep up with the events being generated. — CodeCaster, Dec 22 '16 at 15:34
I understand it's just a curiosity question, not a real performance one, but still: you don't have to think about performance in that case. Overhead of such branch, that will almost always miss is negligible. Especially in places that are so rare like Update (yeah, 60 times per second is not very ofter in this case) See: http://stackoverflow.com/questions/11227809/why-is-it-faster-to-process-a-sorted-array-than-an-unsorted-array — Mateusz Krzaczek, Dec 22 '16 at 15:34
@RomeoTheWizard I'm not entirely sure what your implementation of the coin is, but if it's an object with a collider and a rigidbody you can use the [MonoBehaviour.OnTriggerEnter(Collider)](https://docs.unity3d.com/ScriptReference/MonoBehaviour.OnTriggerEnter.html) function. — Taelsin, Dec 22 '16 at 15:55
This isn't an solution, so I'll just leave it as a comment. Keep in mind that C# does short-circuiting on the IF statements. You can take better advantage of that, by reversing your two conditions. Check the !CoinCollectedBefore first... if a coin has been collected, this will kick out of the IF statement faster than checking the other boolean first. This isn't much of a performance improvement if these are booleans, but if they are more complex or time-consuming conditions, it will help. — Eric Burdo, Dec 22 '16 at 15:57
Assuming this can be done using events. I can't figure out how to deal with the subscription. Where to subscribe and when to unsubscribe. — Jaswir, Dec 22 '16 at 21:30

score 0 · Answer 1 · edited Aug 21 '18 at 17:28

0

Depending on what needs to check for that if condition the usual solution is to create a private bool and then check it if already set.

private bool cachedResult;
protected bool CachedResult
{
    get { return cachedResult ?? (cachedResult = ComplicatedCalculation()); }
}

...

if(CachedResult)
{
...
}

This code checks to see if 'cachedResult' is null. If it is, than it run the ComplicatedCalculation() method to get the result. After that 'cachedResult' is populated and the if statement won't rerun the calculation.

edited Aug 21 '18 at 17:28

Fredrik Widerberg

3,068
10
30
42

answered Dec 22 '16 at 15:35

ChargerIIC

1,620
1
33
47

1

This question is about Unity (a game engine) and collecting coins (a game event). The state can change with every frame (i.e. 60 times per second or whatever the FPS is). Caching is not applicable here. – CodeCaster Dec 22 '16 at 15:36
Unless you a destroying the GameObject and recreating it every frame, caching the setting in the Unityscript will keep the results of the calculation as long as that GameObject is alive. If you are doing something more complicated we'll need code examples. – ChargerIIC Dec 22 '16 at 15:38
I'm not the OP. My point is that your `cachedResult = ComplicatedCalculation()` will only be called once, while it can change with any `Update()`. – CodeCaster Dec 22 '16 at 15:40
@ChargerIIC I understand that the if statement won't rerun the calculation after Cached result is no longer null. But that's not the goal. The goal is that the if statement should no longer check anything (in this case if cachedResult is null) as it's basically served its use. – Jaswir Dec 22 '16 at 20:26

More efficient if statement when only fired once in the game

1 Answers1