Function "call Alias" performance

I've made a little test focusing on speed of executing Function's Aliases. AFAIR:

First version:

1. Start Of Layout
  -> For i=0;i<=9999;i++
    -> Text('myVal') < 10000
    A: Text('myVal') += 1

Second version:

1. Start Of Layout
  -> For i=0;i<=9999;i++
    -> "LowerThan10000"
    A: Text('myVal') += 1
2. On Alias "LowerThan10000"
-> Text('myVal') < 10000
  -> Function Return true[/code:1qafizij]

And Second version's working time was 6-10 times slower . I've been planning on making very complex engine mostly built of "Call Alias". How does "Call Alias" differ from direct conditions when it comes to generate runtime version of game made in Construct? Should I try to minimalize usage of CallAlias in vital places?

There was a discussion regarding using "constant string" and "alternable string" for "for" loops, does this have anything to do with Function's "call alias" (and call function as well)?

I think you can use variable strings with calling functions. I can't see any reason it wouldn't work. I wouldn't advise using variable strings for the 'On function'/'On Alias' conditions though, purely because it'd probably make your code unreadable.

[quote:1ymgciqk]6-10 times slower

Which one is it? 6 or 10? What are your actual figures? Did you try both inline and isolated mode? I think inline should be faster.

Even so, 10 times slower isn't a big deal, remembering that the GPU and CPU are working at the same time and usually the GPU will take longer to get anything done. Also, assuming your code is sanely written, other CPU-intensive tasks like fine collision detection and loops will probably make it a negligable factor. It may be 10 times slower, but that could only be because normal conditions are extremely fast! You'd be a victim of premature optimisation if you were fussing over whether these events used 0.1% or 1% of the CPU time - yes that's a 10 times difference - but it'd have absolutely no noticable impact on the result game whatsoever.

Logically, the 'Isolated' function call has to make sure the called event does not affect the picked objects in the event that called it. So this means a new empty SOL layer, running the event, then restore to the original event's SOL layer. This is actually still pretty efficient, but it's a function of how many object types exist in the application, so it will slow down a bit for bigger apps. In some ways, it's surprising it runs as well as it does!

'Inline' function calls, if I remember right, have very little processing overhead. It'll just run the event allowing it to make whichever changes it wants to picked objects, so it should be a bit faster. Sometimes it doesn't matter which you use, in which case 'inline' is probably preferable for this reason.

Still, it's irrelevant until you know it's a performance issue. This is the rule of premature optimisation: don't do it - it's a waste of time until you've proven your game runs slow because of one specific thing. Until then, you're trying to fix your car by picking an entirely random bolt and tightening it.

6-10: from 6 times to 10 times (counting ticks with profiler), 10000 loops is surely to little, will try another time with more loops if there'd be need for it.

Thanks for reply. I'll stick to making code as easily managable as possible ^^.