This tutorial will explain a little bit about how certain features in the C2 runtime work. And how they can impact your performance. It might or might not be the cause of some slowdowns but it could be worth testing if you are experiencing performance issues in your project. You will likely not have problem with this unless you are targeting lower end mobile phones or is using very large layouts with a lot of instances.
I'm sharing these findings efter investigating it a bit further in this Forum Thread
How to identify and test it?
The debugger can give you a hint if any of these issues might be the problem. When your game is idle and nothing is moving and there's not much game mechanics going on you could be noticing the CPU usage is abnormally high under "Engine" Category. This could be an indication that some of these issues could be the cause.
You can easily test this by:
* Editing your families by removing or replacing family members with a low count object.
* Removing Behaviours that are present on a lot of instances.
* Stop animations from playing, by setting speed 0 to all your sprites with animations, at layout start.
If you notice that your CPU usage under "engine" drops significantly, it might be worth to investigate further, if you should do some optimizations in these areas.
Families
Families is a very useful feature but can have a performance impact especially in large projects if you're using them extensively in large layouts with a lot of instances. It's because C2 runtime is suffering from something called polymorphism. Simplified it basically means that the code is split to accommodate a new Object type (Family). More detailed explanation by Ashley can be found in the above linked thread.
Impact.
If many or most of your object is a member of a family, you can suffer a performance drop, in some projects. The more instances that are a member of a family the more performance drop you will notice.
How to reduce performance drop.
Here are some ways you can combat this if families is the cause of your reduced performance.
Bundle objects in the same sprite. One way is to try bundle sprites in the same sprite and use Animations, and Frames to set witch sprite you want to show. That way you can bundle stuff together without having to use Families.
Use "OR" Blocks.
Instead of including objects in families you can in some use or blocks in your conditions. This can be useful when you can't to group for example scenery and enemies in the same sprite.
Conclusion
If you get a performance hit from families, try reducing the amount of instances that are members of a family.
Behaviours
Behaviours can be very useful in many cases, but using behaviours on a large number of sprites can cause a quite some performance drop. This happens because the C2 runtime will 'tick' those behaviours every tick, regardless if you set them to disabled or not. For example: If you have the solid behaviour set on a large number of sprites, you can notice a some performance drop, especially for large layouts, with many sprites, or for less powerful mobile phones.
Impact.
Every single instance with a behaviour will tick. So it can potentially cause some performance drop. If you can identify that behaviours is the problem somethings your can do is:
How to reduce performance drop.
Avoid using behaviours on large amount of sprites, as every single instance will tick the behaviour, even if deactivated or outside the view. Some ways to reduce this is to:
Use dummy sprites. Instead of having multiple instances with behaviours, you can try to limit the amount of instances with behaviours, such as solid to an invisible larger dummy sprite covering a larger area.
Use Tilemap Object Tilemap can in some cases be used instead of multiple sprites to reduce the number of instances with behaviours.
Conclusion
If you have a lot of behaviours running and it's causing some performance issues, try limit the amount of instances with behaviours as it can use unnecessary resources, regardless if they are disabled or not.
Animations
Animations usually don't cause any issues unless you are using a lot of sprites that are animated. Animations when started will always 'tick' in the background once started and will remain to do so as long as they persist in the layout. Stopping the animation will not help, so if you for example have a layout with a lot of animated scenery you can notice a performance drop, even if those sprites are outside of the screen and stopped. A sprite with animation speed set to 0, or a sprite with only one frame will not have any impact.
Impact.
The impact on animated sprites can vary, depending on how many you use, but it can be good if you can stop them from ticking if they are off screen for example. If you are using a lot of animated sprites you can notice a bit higher CPU usage even when they are most of them are off the screen.
How to reduce performance drop.
This can be a little bit tricky because as long as they are present in the layout the animations will tick once started. So if you're experiencing a performance drop due to a large number of animated sprites there is a few things you can do. Stopping the animation, or setting the speed to 0 will not help once the animation have started.
Reduce the amount of instances with animations. If it's using to much CPU you can just use static images instead in some cases.
Destroy animated sprites outside the view
This can help in very large layouts with a lot of animated sprites that are outside the view. Always have your animated sprites set to speed 0, and when the sprite "is on screen" you can start the animation and set the speed. But once the animated sprite is outside the screen you can destroy the animated one and replace with static one again (speed 0). Constantly destroying and creating new sprites can have a performance impact as well, so you might not get any benefit out of this, but it could be worth trying for large layouts with a lot of animated sprites.
Conclusion
For large layout where most of your animated sprites are outside the view. Try to destroy them, as they will remain to use CPU time ticking when even they are outside the screen.
These optimizations apply for both C2 and the current state of C3, but if you read the above linked thread many of these issues will be resolved once the new C3 runtime goes live.