In coding a physics-based game, I have created everything from subclassed NSObjects. Force vectors are stored in NSArrays for each particle object, then acceleration, velocity, and position are calculated at 60fps with a CADisplayLink.
Version one wasn’t meant to be optimized, but it appears to run very well. CADisplayLink is fast and consistent. However, when I looked at the allocation statistics… Well, I’ve never seen anything like it. ARC does a great job at keeping the Live Bytes under 1 megabyte, but this thing is shredding through 6 gigs a minute of overall allocations.
So my questions are:
Is this code dangerous to run on a device for long periods of time? How “bad” is this? Will apple even accept this or am I going to fry iPads if I continue developing like this?
Optimizing to minimize allocation throughput is an exceptionally effective method to employ.
Notably, every allocation is likely going to require most of the bytes in the allocation to be touched, potentially a few writes and many reads, per every byte in the allocation. All those reads/writes requires CPU cycles and transactions across the system bus.
So, yes, it will eat battery and will increase system temperature. It is unlikely, though, to burn up the device. 🙂
Sort by the “#Transitory” and start figuring out how to eliminate transitory allocations. I typically initially ignore the various Malloc ## Bytes allocations as those are most often backing stores in instances of some class. Eliminate the transitory instance(s) and the # of mallocs drops, too.
For any given allocation type, you can click through to see a list of where all the allocations of that type were created. Sort by the function name and then get a feel for the most common function. Target your optimizations there.
Using this method, I’ve been able to massively optimize some large applications; sometimes reducing the time of execution of certain operations by upwards of 75% by simply minimizing allocation rates!