High "engine" CPU usage when using families.

1 favourites
From the Asset Store
With this template you will learn how to use the GooglePlay Games native plugin
  • It will probably be an on/off thing, i.e. either you get a fixed performance hit to the project, or you don't (I don't think it will get worse if you keep adding families, but maybe we should benchmark that too).

    I already tested that. Adding more families didn't have any impact. If the sprite was a member of 1, or 20 families I noticed no significant difference at the moment. It only seemed to scale off how many instances that were in any family.

    Is there any other features that you can think of that might suffer from this polymorphism issue, I'd be happy to run some tests, and see what kind of performance hit they have.

  • Ashley

    Just out of curiosity I ran the same tests "Quad Issue" with a solid behaviour on the sprite.

    There's no collision checks going on and I noticed a hit of around 40%, even when the solid behaviour was set to disabled.

    So it seems like behaviours are also suffering from this polymorphism issue?

    EDIT: Using two behaviours on the sprite (Anchor and solid) gave me about a 60% drop.

    EDIT2: Adding the effect grayscale on the sprite game me 32000 max sprites, where as original was 180.000

    But adding the same effect to the Layer instead of the sprite showed now significant drop.

    EDIT3: Adding solid behaviour to either the family or the sprite gave another hit of about 10%. from 180.000 to 95.000

    This is quite good to know now for performance issues. Families, behaviours, effects, all seem suffer from this polymorphism so it's wise to use them sparsely, but it's a bit sad that we're missing out on that much performance, due to this. On the good side..... it's being worked on.

    It completely changes the way I will design my games and levels knowing this, until the new runtime drops.

    Conclusion

    So would it be safe to assume that behaviours also suffer from this polymorphism issue? Having a lot of sprites with solid behaviour will suffer this issue? And disabling or enable behaviors didn't have any effect on this polymorphism.

  • I don't think these other cases are the same polymorphism issue.

    I noticed a hit of around 40%, even when the solid behaviour was set to disabled.

    Currently the C2 runtime unconditionally ticks all behaviors. The solid behavior does not need ticking, so this is wasteful when you have a lot of instances. The C3 runtime is smarter and only opts in to ticking the behaviors that need it. So I tested this as well and in the C3 runtime, adding a solid behavior does not impact the performance in the quadissue test. (This isn't polymorphism, it's just better design.) Some behaviors do need ticking though (generally the movements), there probably won't be much change for them, but for those it has to do per-tick work anyway so it's necessary.

    [quote:15a6nvsr]EDIT2: Adding the effect grayscale on the sprite game me 32000 max sprites, where as original was 180.000

    But adding the same effect to the Layer instead of the sprite showed now significant drop.

    Rendering effects has quite a high overhead per effect, and using a layer effect instead when you have a lot of instances is already in our performance advice. Rendering effects is complicated so there will probably be quite a high per-effect overhead in the C3 runtime too, but this also isn't polymorphism, it's just that rendering effects involves extra work.

  • Thanks for the explanations ASHLEY. Seems like we're looking for quite a bit of performance improvements with the new runtime.

    Is there any rough estimate on when the runtime will ready for beta or the masses? I'm mainly thinking if I should spend time now to optimize my projects with the new found knowledge of polymorphism (family) issue, or keep going and plan release when the new runtime is ready?

    Seems like many of these issues affecting performance will be non-issues with the new runtime.

    Now get back to work and stop crawling the forums so we can have those improvements sooner rather than later.

    Exciting times indeed!

  • Hopefully I'll be able to post more news about the state of the C3 runtime by early next year. I just don't want to commit to too much yet. It'll be our main priority after the full launch of the C3 editor, though.

  • Hopefully I'll be able to post more news about the state of the C3 runtime by early next year. I just don't want to commit to too much yet. It'll be our main priority after the full launch of the C3 editor, though.

    Thanks. While we're on the topic I found another little quirk now. Using the same example "Quad issue".

    Adding another frame to the "sprite" object seems to have a performance impact as well (about 25%) But it only happens if you set the speed to anything else than 0.

    Repeat count is set to 1, so the animation should stop after the first loop. But somehow even if the animation stopped playing after the first loop, it not actually stops unless you specifically set speed to 0 at start of layout.

    Adding an event to to set speed to 0 or "stop animation" action with a mouse click didn't seem to stop the animation or reduce the load either, and decrease the CPU load. It's still using more CPU if an animation has been run. It never really stops. And if you use a lot of sprites with animations you will notice this performance drop.

    Attached a modified c3p here

    https://www.dropbox.com/s/kfy9zew4bxlkh ... f.c3p?dl=0

    Click should stop the animation completely.

    Try setting animation speed to 0 and the performance is back to normal.

    Conclusion:

    Sprites with animations stopped or not will never really stop once started, even with events stopping the animation, and will cause an increased CPU usage as long as they persist in the layout.

  • This is interesting stuff. I use a ton of family in my projects and have notice this as well too. Good to see this is being addressed now.

  • Adding another frame to the "sprite" object seems to have a performance impact as well (about 25%) But it only happens if you set the speed to anything else than 0.

    Yeah, this is another deliberate optimisation which only applies some of the time. Animated sprites need to be ticked to advance the animation frame, but to avoid the ticking overhead for static sprites, if it has only 1 frame or an animation speed of 0 it doesn't tick it at all. This is so all your static scenery and background objects don't get the overhead of ticking if they're not animating. It will start ticking if you set the animation speed greater than 0 (and it has more than 1 frame), but one quirk is it never stops ticking that instance until it is destroyed, i.e. it assumes it will always be animating thereafter.

    I think this is pretty reasonable, the main goal is to remove overhead from static objects, and it does the job. However it's true that we could refine this a bit so as sprites stop playing animations they also stop ticking, and only start again when they start animating again. I've made a note to look in to doing that for the C3 runtime.

    Adding something to the quadissue test and measuring the impact seems to be a good way to measure the engine overhead of various features! I'd warn though that the overhead isn't necessarily always important - for example in the animated sprites case, I would guess for most projects sprites either animate or don't, so the ticking overhead issue probably isn't particularly significant.

  • Yeah i agree, some might not be that critical, but I tested this because I was thinging if you have a layout with a lot of grass turfs with animations blowing in the wind it would be good if you can properly stop them from ticking especially if they are off screen. A lot of small things add up, even small thing like grass turf animations, water animation sprites, canopy etc etc.

    Edit: tried another setup of this as well, and off screen animations seems to tick as well. So if you have a good ammount of animated scenery, it could potentially animate (tick) off screen even though you don't see it.

    So being able to completely stop ticking for sprites would be good. As the stop animation action doesn't stop animations. Only freezes the frame, is that correct?

  • tunepunk Wow those are some great findings! I think it explains a lot of the strange issues that we (and by extension our Steam customers) have experienced with our 2D platformer.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • It is also an issue in c2. I didn't do tests per say, but I did notice that once I added a family, performance would always start going downhill. Same for animations.

  • [quote:3qgzqf3o]The good news is... I've actually got enough of a working prototype of the C3 runtime to benchmark this already, and the C3 runtime does not have any performance impact when you add a family. So this is a nice confirmation that the new engine is indeed going in the right direction with its architecture, and should fix this problem throughout the engine. This could mean quite a big performance boost for large projects!

    After reading so much drama news my heart skipped on this last part! Awesome, looking forward to the new engine (though until then I'll remove my families )

    tunepunk great work finding all these things, I especially love the conclusion summary part.

  • great work finding all these things, I especially love the conclusion summary part.

    Thank the original poster who pointed it out. I simply tried to dig a little deeper, as I have been noticing similar issues myself.

    With these new findings I'm gonna try do a small tutorial with performance tips to combat these issues.

    Families, Behaviours and Animations are so widely used in most projects. So now that we know a little bit more about how the C2 runtime handles these things it's good to inform people so they can make changes in case they experience performance issues, where any of these things possibly could be the cause.

    I'll be referencing this thread with Ashley's explanations so that people can get a deeper understanding on what's going on under the hood.

    I wouldn't say these are issues that would break projects, but it's good to know what might cause a bit of a slowdown if you're using any of those features extensively.

  • https://www.scirra.com/tutorials/9608/p ... animations

    Just posted a small little tutorial here on these issues, and how to deal with some of them. Now I can't wait for the new runtime to drop.. <img src="{SMILIES_PATH}/icon_e_biggrin.gif" alt=":D" title="Very Happy">

  • tunepunk Good summary, a very good read indeed.

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