Do event conditions early-out?

Discussion and feedback on Construct 2

Post » Tue Mar 13, 2012 3:02 am

Hey,

I just had a quick performance related question about the event system: do the conditions on an event "early out"?


Say for example I have an event triggered by the following conditions:
- MouseClick on Sprite
- if someVariable = true
- if someOtherVariable = true

So logically, the event triggers when the mouse is clicked on a sprite object if someVariable and someOtherVariable are both true.

If someVariable is false in my example, would construct bother to check the value of someOtherVariable, or will it be clever enough to early-out and skip that check?


I ask because I have a couple of events with reasonably complicated conditions and I'm wondering if I should bother arranging the conditions in an order that could take advantage of an early-out to skip un-needed checks.

I am aware that the performance impact would be fairly minimal, and that where possible it's better to design less complicated events or break things down to sub-events anyway, but small differences can add up on a mobile platform and I'd like to know if this is an area worth spending (and admittedly minimal amount of) effort on?



Lastly, if conditions don't early-out, consider this a suggestion that if it is not overly difficult to make them do so they should!


Thanks for your time!
B
24
S
5
G
2
Posts: 104
Reputation: 3,136

Post » Tue Mar 13, 2012 3:34 am

By default logical operators in JavaScript early-out (more commonly called 'short circuiting'), so I can't see why Ashley would override that behaviour. As far as C2 is concerned I'm not sure. This would be easy enough to test.

- If someVar = true And someOtherVar + 1 = true

If someVar is false and it short circuits someOtherVar will not get incremented. If it doesn't short circuit someOtherVar will get incremented.
B
17
S
6
G
6
Posts: 113
Reputation: 4,161

Post » Tue Mar 13, 2012 3:35 pm

That is in fact the case - if you do a test with a simple check of a global variable first followed by a cpu intensive condition like checking if a thousand sprites are overlapping a thousand other sprites, the framerate only dips from the second condition when the global variable check is true, showing that the collision check is entirely skipped.
Moderator
B
88
S
32
G
33
Posts: 3,005
Reputation: 27,432

Post » Tue Mar 13, 2012 3:39 pm

Conditions do early-out - there's no reason to waste CPU running conditions when the event is already known to be false!

It would probably be difficult to measure a performance impact from rearranging conditions though - often rendering takes up a lot more processing than the game logic.
Scirra Founder
B
359
S
214
G
72
Posts: 22,952
Reputation: 178,580

Post » Tue Mar 13, 2012 8:30 pm

Thanks!
B
24
S
5
G
2
Posts: 104
Reputation: 3,136

Post » Tue Mar 13, 2012 9:53 pm

Apparently collision checking is something big to watch out for. I suppose then, you should arrange collision checks to be at the end?
B
90
S
30
G
24
Posts: 3,189
Reputation: 32,400

Post » Tue Mar 13, 2012 10:40 pm

Collision checks can be one of the most intensive conditions, but of course that depends on the number of objects and points involved. So yeah, if it doesn't disrupt the flow of logic, you might as well.
Moderator
B
88
S
32
G
33
Posts: 3,005
Reputation: 27,432

Post » Wed Mar 14, 2012 1:30 am

I asked about collision not long ago, basically 'collision' and 'overlap' are the same thing (except collision has a hidden "trigger once" next to it) except with 'overlap' since it is not a "trigger condition" you can place it further down a list of conditions so it's not checked as often.alspal2012-03-14 01:33:23
B
134
S
65
G
16
Posts: 1,766
Reputation: 19,190


Return to Construct 2 General

Who is online

Users browsing this forum: No registered users and 12 guests