Why Do Timers Consume CPU If They Are Not Triggered?

  • I thought Triggers they don't Consume Cpu unless they are triggered but not on this case. On an iPhone 8 this simple Test With no events Running just Events for Timers which they never get Triggered consumes (17 To 20)% CPU

    is this a Bug?

    https://www.dropbox.com/s/qu0by2iq9fzlklv/Timers%20consuming%20CPU.capx?dl=0

  • Interesting find! It appears that timers are not that performance-friendly as I thought they are..

    I'm guessing the "On timer" is not truly a triggered event (like "On mouse click" for example). When "On timer" is present in the code, the system checks all object instances on every tick, regardless of whether they are running any timers or not.

  • tarek2 have you tried cpuutilisation instead of using the debugmode? Some behaviors behave different in the debug-mode even in profile, not inspect.

    You could try cpuutilisation in the debug 'profile' and in the normal preview for equal comparison.

  • C2 checks each behavior each tick, you got 2. So even with basic check, it will cause high cpu on phones. Not to mention you trigger with behavior + no value, so its some big mess :D

  • tarek2 have you tried cpuutilisation instead of using the debugmode? Some behaviors behave different in the debug-mode even in profile, not inspect.

    You could try cpuutilisation in the debug 'profile' and in the normal preview for equal comparison.

    Hi Asmodean sure mate I tried that already but that gives me even worse Results

    Example To make the Test Fair I removed the Platform behaviour & I make all the sprites Invisibles

    iPhone 8 Results with

    The Group "Timer" Active = around CPU 44%

    The Group "Timer" DeActive = around CPU 14%

    Using Txt display

    Here is the capx if anyone wanna Test it

    https://www.dropbox.com/s/xc4t8oqq1vvb1m9/2-Timers%20consuming%20CPU.capx?dl=0

    SnipG

    C2 checks each behavior each tick, you got 2. So even with basic check, it will cause high cpu on phones. Not to mention you trigger with behavior + no value, so its some big mess :D

    I know that already mate but I think you missing the point here, it shouldn't be that expensive to check Triggers I would say around 1% or less but is my fault I give a bad example for you guys to test, I created another example to demonstrate my point.

    This Time using Turret as an example:

    If you check this capx that is how it should work The Timers

    looking at the Debug profiler The Group "Timers" uses around 0.3%

    https://www.dropbox.com/s/ovb4lvsgjzmy9as/3-Timers%20consuming%20CPU.capx?dl=0

    iPhone 8 Test Results

  • Not only are you checking the timers every tick. You have 330 instances checking every tick.

    Also the "For each" doesn't do anything here.

  • Hm...is it possible to turn a "script" on / off, like in unity. In terms of C2 the question would be if it is possible to activate / deactivate "command-lines". F.e. in a situation where you only fire a trigger-listener, when it´s in a specific action-"radius". Would something like this prevent abusing too much CPU power ?

  • Not only are you checking the timers every tick. You have 330 instances checking every tick.

    Can you be more specific please, so it's a fake trigger then?

    What is the Difference Between Example a Trigger from (Turret Vs Timers)

    Because all the 330 objects use Turret yet the CPU = Less than 1% for the (Timers Group)

    Also the "For each" doesn't do anything here.

    I was Testing Picking groups of objects with The Timer and you need the For each there when is more than one object triggering at the same Time but I forgot to remove it but it shouldn't affect anything for the purpose of this test

  • I think there may be a bit more overhead on named timers than something like the behavior timers because those are in code, and then converting a string takes a bit too.

    Edit:

    I should be specific. Events run every tick. Triggers, unless filtered, also run every tick. They just don't do anything if they don't meet conditions.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • tarek2 If you look in the edittime.js from the timer-behavior you will see it's a 'fake triger':

    cf_fake_trigger

    Appears and works exactly like a trigger in the editor, but is passively evaluated every tick in the runtime like an ordinary condition. You cannot specify both cf_trigger and cf_fake_trigger. Fake triggers are useful for conditions like "Every X milliseconds", where the condition should work like a trigger in the editor, but it is most convenient to implement it as an ordinary condition in the runtime. Fake triggers cannot be triggered by runtime.trigger(): they are identical to ordinary events in the runtime. This flag only affects the editor.

    That explains the CPU Usage and like newt wrote: it has 330 instances (in debug) à 7 timer events. That's quite a lot. If you use full screen it's even more because you use WindowHeight/Width not OriginalWindowHeight/Width. So the amount of instances changes with the size of the Window.

  • I think there may be a bit more overhead on named timers than something like the behavior timers because those are in code, and then converting a string takes a bit too.

    Edit:

    I should be specific. Events run every tick. Triggers, unless filtered, also run every tick. They just don't do anything if they don't meet conditions.

    newt I see what you mean now Thanks a lot mate

  • tarek2 If you look in the edittime.js from the timer-behavior you will see it's a 'fake triger':

    cf_fake_trigger

    Appears and works exactly like a trigger in the editor, but is passively evaluated every tick in the runtime like an ordinary condition. You cannot specify both cf_trigger and cf_fake_trigger. Fake triggers are useful for conditions like "Every X milliseconds", where the condition should work like a trigger in the editor, but it is most convenient to implement it as an ordinary condition in the runtime. Fake triggers cannot be triggered by runtime.trigger(): they are identical to ordinary events in the runtime. This flag only affects the editor.

    That explains the CPU Usage and like newt wrote: it has 330 instances (in debug) à 7 timer events. That's quite a lot. If you use full screen it's even more because you use WindowHeight/Width not OriginalWindowHeight/Width. So the amount of instances changes with the size of the Window.

    Asmodean Awesome Thanks for the full Explanation mate, everything makes sense now, you see I would have never thought that Timers are fake triggers I noticed just by accident, the true I was hoping that someone tells me is a bug as I was making some game with 200+ objects that they need definitely use Timers my heart is broken now Im gonna cry jeje I have to spend Time now to figure out if this can be done without affecting too much CPU

    Ho yeah about the "WindowHeight/Width" it was on purpose I wanted to spawn as many Sprites as possible to show clearly the Cpu overhead,it was just for the purpose of this test I don't normally use that on a real Game but thanks anyway :)

  • Thanks to Everyone who contributed to this thread I really appreciate it :)

  • I wouldn't worry too much about it. While there was a good amount of cpu usage, given the amount of instances it wasn't that bad, and there is filtering as Spax was aking.

    Is on screen, instance variables etc.

    Just avoid the "For each" as much as possible. It's the bigger gotcha in all this.

  • I wouldn't worry too much about it. While there was a good amount of cpu usage, given the amount of instances it wasn't that bad, and there is filtering as Spax was aking.

    Is on screen, instance variables etc.

    Just avoid the "For each" as much as possible. It's the bigger gotcha in all this.

    newt indeed, after I made some changes Exported the Test then I checked again and I did some calculation but this Time I checked CPU with different Tool than c2 and doesn't look bad, Removing the Cpu that the Objects alone consume without Timers and comparing against the other Test with Timers it looks ok, the Cpu Debbuger from C2 it was over exaggerating. it's all good now I'm happy with the Results that I got.

    Good to know for the future to avoid situations like this.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)