What is slowing my game to 5fps every 10 seconds or so? (Console log attached)

Hi everyone,

I noticed every 10 seconds or so the frame rate of my game slows dramatically. I’ve used the Xcode console although I’m still unsure as to what the problem is.

Here is the output of the Console in Xcode for one of the times where it slowed down a lot. The physx is quite high although during the time that this reading occured I don’t believe there would have been any more calculations for the Physx as I was doing exactly the same thing as normal in the game. (No special buttons were pressed, or abnormal animations on screen etc…)


iPhone Unity internal profiler stats:

cpu-player> min: 47.2 max: 513.7 avg: 105.8

cpu-ogles-drv> min: 1.9 max: 8.3 avg: 2.5

cpu-waits-gpu> min: 0.2 max: 0.8 avg: 0.2

msaa-resolve> min: 0.0 max: 0.0 avg: 0.0

cpu-present> min: 0.8 max: 11.6 avg: 1.5

frametime> min: 57.7 max: 526.9 avg: 113.5

draw-call #> min: 42 max: 46 avg: 43 | batched: 1

tris #> min: 10067 max: 12326 avg: 11095 | batched: 126

verts #> min: 5065 max: 6219 avg: 5605 | batched: 86

player-detail> physx: 62.9 animation: 14.9 culling 0.0 skinning: 1.3 batching: 0.0 render: 6.5 fixed-update-count: 3 … 25

mono-scripts> update: 13.8 fixedUpdate: 2.2 coroutines: 0.1

mono-memory> used heap: 610304 allocated heap: 2387968 max number of collections: 0 collection total duration: 0.0


This can be compared to the normal reading (and frame rate) I get the majority of the time which gives the following as output from Xcode.


iPhone Unity internal profiler stats:

cpu-player> min: 47.8 max: 73.7 avg: 57.2

cpu-ogles-drv> min: 1.9 max: 9.2 avg: 2.6

cpu-waits-gpu> min: 0.2 max: 0.3 avg: 0.2

msaa-resolve> min: 0.0 max: 0.0 avg: 0.0

cpu-present> min: 0.9 max: 6.7 avg: 1.3

frametime> min: 54.9 max: 87.0 avg: 65.0

draw-call #> min: 41 max: 44 avg: 42 | batched: 0

tris #> min: 7899 max: 10847 avg: 9340 | batched: 0

verts #> min: 4009 max: 5433 avg: 4711 | batched: 0

player-detail> physx: 33.2 animation: 5.3 culling 0.0 skinning: 1.2 batching: 0.0 render: 5.9 fixed-update-count: 3 … 4

mono-scripts> update: 8.8 fixedUpdate: 1.1 coroutines: 0.0

mono-memory> used heap: 716800 allocated heap: 2387968 max number of collections: 0 collection total duration: 0.0


You can see that of the two readings, the one that really slows on the device as a greater ‘cpu-player’ max, higher FixedUpdate count as well as Physx and animation values.

Perhaps it’s something to do with the CPU? If so, would that only be possibly affected by the scripts running and therefore I need to look there?

Thanks in advance for any light you can shed on this!

Similar Unity Answers post (slightly different wording but same problem);

Optimise it. The subject is far too broad to go into for this post since we don’t know what you’re doing. But the regular slowdown is 99.9% likely to be a spike from the garbage collector.

This means the following (which you should search forums for):

  1. use pooling, don’t instantiate and destroy in game
  2. don’t allocate and destroy any variables in your update loops
  3. batch stuff. from looking at it above you’re batching nothing
  4. if using js, use #pragma strict and #pragma downcast at the top to force you to strongly type everything

Following those principles are a good start, and you can search forums and even help docs for optimizations, there are literally thousands of posts dealing with each kind of optimization necessary.

Every 10 secs a big slowdown is because your garbage collector is hauling out tons of trash, instead recycle stuff so it doesn’t need to spend so long shifting your leftover rubbish and beer cans.

I had the same problem. Even in nearly complete empty scenes I got “hickups” every 5-10 seconds.

You have to change following in your AppController.mm

Change this:

To this:

This solved the problem completely for me.

I’m glad I found this post. I was just running my game on the device, in it’s very early state, and I was noticing some “hiccups” as well every few seconds. There’s not much in the scene so I was hoping someone might have run into the issue already. Thankfully the solution you provided WORKS!

I am curious as to what the implications are with using an NSTimer based loop vs. the standard Thread based loop. If anyone knows, please share the knowledge.

In any event, thanks a lot for this.

Different main loop style might improve stability, but you still heavily bound by Physx and your script updates. It is healthy to have physx under 10 ms and your script updates under 5 ms.

For tweaking physx you might want to play with time and physics manager settings : Unity - Manual: Time , Unity - Manual: Physics.
But usually it requires to redesign what and how your game uses physics components (i.e. substituting mesh colliders with more simple ones, adding rigidbody to the colliders that move, etc.)

For script performance tuning remote profiler might help (iOS Pro license only).

So adding rigibody helps performance with moving colliders? I always stayed away because I thought that was just more for the processor to calculate

Yes, adding kinematic rigidbody will hint PhysX that this object might move, thus letting it assign to the correct object queue and save some processing time.

Very cool, so should I replace a character controller with a rigibody? Or is an object that uses a character controller OK?

Yes, it’s extremely important to have a rigidbody (iskinematic or not) on any object that moves.
In a complex scene on a 3GS, with around 40 object moving around, one single object without a rigidbody moving around was causing my player-detail> physx in the profiler to climb as high as 8 or 9, dropping my framerate from constant 60fps to around 45.
Just adding a rigidgbody with iskinematic dropped my physx in the profiler to around 1 again.

This is extremely noticeable on 3GS, because the added CPU power on iPhone4 and iPad helps a lot with Physx.

Awesome info here.

As Hippocoder said, this is a broad subject. However, the subject of this thread caught my attention because this is the exact issue which started me down the road to pooling. For me it was the garbage collection causing the stutter. I hate that many of my posts read like an infomercial, BUT, PoolManager was born to solve this in our game. If you are having the same issue, maybe it will help you too.

I would, but $30 is too much for something I have already done. If I accidentially managed to get a discount on it, I would of course, probably just to see if it was faster than my List based method :slight_smile: