Profiling/Optimizing your game code?

Started by
5 comments, last by Alberth 7 years ago
My game was originally just a tech demo that evolved into a highly anticipated game for many, so when I wrote it, I wasn't thinking about optimization or speed. Now the code is a mess like Lugaru and it needs to be optimized for battery life and CPU usage.

So my question is, what's the best way to go about this? Now, as a heads up, this game is primarily coded for Mac and iOS, with Windows and Android ports built every so often. When running my game on iOS 9.3 devices, the CPU usage is low. But on iOS 10 and macOS the CPU usage is too high. (Please don't troll, thanks).

Now, I am aware of the macOS tool called instruments iirc, and it measures the number of milliseconds it takes to execute a function and so on. Even Microsoft visual studio has the ability to tell you per operation as you step through. How do I know if a function is taking too long? One thing that could help optimize my game is using a different ogg vorbis player, other than stb_vorbis since it's CPU usage is a bit too much.

There aren't many draw calls at the title screen, and the CPU usage is still high so I'll start there.

Any helpful ideas? Thanks.

Shogun.
Advertisement

How do I know if a function is taking too long?

I mean, you already gave yourself the answer (use a profiler). Profile your game with a profiler and see in which functions the greatest percentage of time is spent. Analyzing the results of a profiler takes some practice, but there should be lots of good information online.

There's no point in switching to a different ogg player until you know that's the issue.

Not quite. How many milliseconds is too many? It doesn't tell me a percentage (at least I didn't see it). So I don't know how long it's supposed to take.

And it's already been pointed out to me that stb_vorbis is slow, with benchmarks to demonstrate. The audio streaming thread's load is too high also.

Shogun

If you are not using Metal, the obvious first step is to use Metal.

The Time Profiler in Instruments tells you how long each function takes. How long is "too long" is up to you. Once you have profiled your game, you may immediately see something suspicious.

Other standard tactics for reducing CPU usage apply, such as reducing framerate, avoiding the use of the camera or other peripherals, balance thread priorities, etc.


L. Spiro

I restore Nintendo 64 video-game OST’s into HD! https://www.youtube.com/channel/UCCtX_wedtZ5BoyQBXEhnVZw/playlists?view=1&sort=lad&flow=grid

Not quite. How many milliseconds is too many? It doesn't tell me a percentage (at least I didn't see it). So I don't know how long it's supposed to take.

What you need to do is think about things like what framerate you want to achieve, and then that tells you how much time you can spend in a frame. Then when you use the profiler you can see how long everything is taking, and what parts are the biggest users of CPU time. That's where you then focus your efforts. For example, if you see that 80% of your time is spent in 1 function, then you look at that and try to optimize it... or eliminate it altogether. You have to use your knowledge of your code to decide if you need to do architectural changes or function-level optimizations.

Generally optimizing is a very broad and difficult thing, so it's hard for us to give you good advice without really knowing what your code is doing, or seeing some profiling data. There's too many questions... are you using multi-threading, are you doing a lot of loading, memory allocations, a lot of math, etc.

How many milliseconds is too many? It doesn't tell me a percentage
16 is too many. Divide the milliseconds by 16 to get a percentage.

You can also see profiler output as relative measurements.

Your CPU usage is too high, something has to get faster. Profiler gives you areas that take more time than other areas. The former are of interest, because likely, you can improve there, and you'd gain a lot then.

If something takes 500 seconds, and one area takes 50 seconds, and the other area takes 450, I can spend time to eliminate the 50 second area, which at best gives me 50 seconds gain. If I work on the big area and eliminate it, I gain 450 seconds. In other words, in the best possible scenario, it doesn't pay to optimize the areas with small time, as it doesn't help significantly in the overall result. In reality, stuff is a little more complicated, as the 450 area is likely does more work etc. Also, complete elimination is not likely to happen, since you're doing useful work in each area.

My strategy is to check all areas, finding out why it takes the time that it needs. I start with the bigger areas, as any gain there is likely to help a lot, and switch to smaller areas when the bigger areas become too complicated to optimize further, or when the differences between "bigger" and "smaller" are reduced enough.

In practice, I never reach the "all areas checked" state, as after some improvements, it is running "fast enough" again, and I am done.

This topic is closed to new replies.

Advertisement