Debugging high battery usage pre-release

Hi all,

I have a pre-release app that is using a lot of battery. It's a game and is quite a 'busy' app so expecting some significant battery drain. But we want to optimise the app and find out where we can do that most effectively.

Apple seem to have removed a lot of the energy use debugging tools recently. Specifically,

• removed energy use from debug profiling menu in Xcode

• removed 'energy usage' profile from Instruments tool

• while Xcode organiser has an 'energy' section, apparently the logs aren't populated until the app has at least a few thousand users

Is there any logic to Apple removing all these energy usage profiling tools? What's the best way of debugging/isolating energy usage & battery drain in a pre-release app these days?

TIA

Typically the CPU usage percentage is a decent proxy for energy drain when optimizing something that’s mostly busy like a game. The instrumentation that was removed is typically for tuning code that runs all day and does lots of very light workloads, so they were good at finding subtle issues, for example, leaving CoreLocation in a high accuracy mode (GPS is more expensive than say using the cell towers or WiFi hot spots for location).

In your case, you’ll want to use the Time Profiler to see where your code is spending its time. Reducing the total time spent on CPU will generally give you energy efficiency gains. Since you can’t directly control the frequency of the CPU, your goal should be to get the CPU back to the idle state as quickly as possible, so that you remain in that idle state for a larger portion of your frame time. This is usually accomplished by finding faster ways to do the same thing, or not doing the thing you’re doing as often. That’s really vague but hopefully you get the gist.

The GPU in a game, however, can also be where the bulk of the energy cost will come from. Even though the GPU isn’t as fast as the CPU, each cycle is computing dozens of things in parallel which takes more energy per cycle. You can use the Metal System Trace template in Instruments to help you understand the cost of your shaders. Reducing the number of fragments you need to handle is generally the best way, and this can sometimes be handled by reducing resolution in certain parts of the rendering where it’s less noticeable -- see the Variable Rasterization Rate feature in Metal.Vertices could also be a problem, but in my experience, reducing the size of a mesh will contribute more visual compromises than reducing the number of fragments you need to handle.

Assuming you have a typically game, and most of the effort is in the CPU/GPU time spent, I wouldn’t pay too much attention to network usage, location, or timer reduction we’ve advocated in the past because any savings you make there will likely be erased by running the CPU/GPU hard in a game context.

Debugging high battery usage pre-release
 
 
Q