Those of you who follow me know that I’m working on a game that will have ~200 nodes on the screen updating every frame. Because of that requirement, I’m constantly looking at how I can incrementally improve performance. Slowly but surely, I’m making this game a well oiled machine. Today, I stumbled on a significant slow down, and the resulting fix that shaved off 16% CPU usage: caching enumerateChildNodesWithName.

This discovery came from reading WWDC 2014 transcripts while discussing said function.

This is very fast, so you can do it often but we do recommend your cache results if it becomes a performance problem.

Best Practices for Building SpriteKit Games

If it warranted a mention in Apple’s discussion, it deserved a closer look. So, I set up a test with 105 nodes running in the update loop. Here are the results:

• Calling enumerateChildNodesWithName each frame: 44% CPU
• Caching update callbacks in an array: 28% CPU

Huge gains, and the best part that the caching is relatively painless to implement.

Implementation

First, we’ll start with an array to hold our callback functions.

var updateListeners : Array<((CFTimeInterval) -> ())> = []

Here is an example of what one of those callbacks would look like:

    func updateWithTime(currentTime:NSTimeInterval) { 
        // do something 
    }

With that in place, all we have to do is cache the callback functions on the first run through of enumerateChildNodesWithName<strong> in the Scenes update loop.

Now, let’s say one of our characters dies. We don’t want the update function to keep running on that character. We’ll have to clear the cache by emptying the array. Then, it will automatically rebuild on the next update loop.

self.updateListeners = []

I’ve consolidated all of this into a small class that I call from my scene object in case it gets more complicated down the road. You can see my full code here:

Notes & Concerns

Each time you clear the cache, it fully rebuilds. If you’re pushing CPU limits already, this could cause some delayed frames. Two solutions to improve this:

• Add a removeUpdateListener() function, and a key/value store, so that you can remove a specific item on demand.
• Or, break apart your objects into smaller cache groups with the goal of minimizing the amount of objects removed from the cache at any given time.

Consider expanding updateService to dynamically control what would be in the cache. My example is hard coded to Characters and Heraldry, but the situation could be different each level.

Also, this can be a useful way to begin separating out updates for different objects by different time intervals if everything doesn’t have to tick 60 times per second.