I turned off collisions for my weather effect "paricle" objects because they aren't needed... and CPU usage dropped from 15% to about 8% when the weather is coming in "heavy".
Having un-needed collision checks does seem to make a difference, especially when there's a lot of them happening.
Yeah. Turning them off is always good when not needed, but constantly updating on/off is another thing. I have one project where i turn off collisions based on if they are on screen or not, and if you're moving around a lot in the layout, The turning on/off seems to be causing some jumpy scrolling.
Sprite - Is on Screen -> Collisions Enabled
Sprite - Is not on Screen - Collisions Disabled.
So if you have a lot of sprites constantly moving in and out of screen, switching from disabled/enabled seems to cause some hiccups. Constanlty Z ordering all sprites in layout seemed to have a similar effect, so I optimized my Z ordering to only sort objects that actually needed to be sorted. For my isometric game, I'm only sorting 2 instances at any given time, the one in front and the one in back, and only if:
Pick by evaluete: Family1.Y > Family2.Y & Family1.Zindex < Family2.Zindex
Pick by evaluete: Family1.Y < Family2.Y & Family1.Zindex > Family2.Zindex
-> Call function Order (param 0: Family1.UID) (param 1: Family2.UID
On function "Order".
Pick Family2 by evalute: function.Param(0) &function.Param(1)
Family2 is on Screen
-> Set Family2 instance var "SortValue" to. Family2.Y
-> Sort Z Order by Family2.SortValue
// This causes the the function to trigger only 1 time, since the function will sort only any objects that does not have the correct sorting, and all the previous events will be false, so no more sorting is needed.
This blogpost explains a bit why Z order has to be preserved in render cells. That's why I optimized my Z ordering, but it seem's turning collisions on and off, on the fly is heavier than just keeping them on, and could be causing the stuttering I'm experiencing.