Question by anshul-bhardwaj · Jul 12, 2012 at 08:52 AM · ios profiler

iPhone 3GS Performance issue.

Here is the profiler test for iphone 3gs...

iPhone Unity internal profiler stats:

cpu-player> min: 84.5 max: 312.4 avg: 162.2 cpu-ogles-drv> min: 3.5 max: 6.2 avg: 4.3 frametime> min: 95.1 max: 332.5 avg: 174.0 draw-call #> min: 37 max: 43 avg: 38 | batched: 21 tris #> min: 14876 max: 17494 avg: 15105 | batched: 664 verts #> min: 25250 max: 33599 avg: 25880 | batched: 462 player-detail> physx: 113.5 animation: 0.1 culling 0.0 skinning: 0.0 batching: 0.1 render: 7.3 fixed-update-count: 5 .. 16 mono-scripts> update: 4.1 fixedUpdate: 33.2 coroutines: 0.1 mono-memory> used heap: 618496 allocated heap: 860160 max number of collections: 10 collection total duration: 70.3

my game is totally physics base, having 10-12 box colliders which are always active in a fast moving truck vehicle. Any suggestion how to improve the performance. Thanks.

EDIT: alt text

screen shot 2012-07-13 at 5.19.14 pm.jpg (191.0 kB)

Add comment · Show 10

Maddogc · Jul 12, 2012 at 04:23 PM 2

A good start point for performance improvements is unity's own guide (ios performance) and the physics section might be the interesting part for you. I found this article also useful. Try to keep your draw calls as low as possible and to batch as many objects you can, this should pushes up your performance for the beginning...

Bovine · Jul 12, 2012 at 04:58 PM 0

Yep you're spending >100 $$anonymous$$S doing physics and this sample suggests a lot of garbage collection is going on. Avoid allocating anything once your playing your game. You're spending quite a while in many areas of code, your budget is around 32$$anonymous$$S (for 30fps) and you spend more time than that in fixed updates.

I think we would need more detail on your game to help but what is your truck running on? $$anonymous$$esh colliders? Is it one huge one? Performance may improve if you reduce the complexity of mesh colliders and subdivide them.

Do you really need 12 box colliders for a truck? Is your app a game or a simulation? Could you simplify the physics mechanics and still achieve acceptable results?

On average your game is running 3x slower than you need at the $$anonymous$$imum and 10x slower at the maximum. You may also want to achieve 60fps as its a racing game!

anshul-bhardwaj · Jul 13, 2012 at 05:46 AM 0

@$$anonymous$$addogc & Bovine: Thanks for the suggestion but as its a racing game, i cann't increase the fixed time step, right now its set to 0.02.

@$$anonymous$$addogc: u said try to decrease the draw calls but i want to ask is it useful in my case as its cpu bottleneck.

@Bovine: yes, truck is running on $$anonymous$$esh collider having around 1000 tris for track and 400 tris for side colliders, truck is made up of 4 scaled box colliders and it cotains around 12 box colliders, actually it is working fine on ipad so i cann't reduce the no. of box colliders as it change the game play in devices. you said subdivide the mesh collider, can you please suggest me some method to do that.. you means load the mesh collider at runtime according to the truck position on the track? is it useful?

so what i am thinking to do next is optimize scripts and try to reduce the garbage collection.

Bovine · Jul 13, 2012 at 07:40 AM 1

It may run okay on iPad (which version?) but your collision model is quite huge for mobile devices - 12 boxes to define your truck is too many in my view and you will need to reduce that number to as few as possible I$$anonymous$$HO. The time you spend in your physics should be the absolute $$anonymous$$imum to achieve the level of simulation you're after. Right now you're happy with your simulation but I would say:

I can't imagine you don't have problems on iPad 1 and possibly 2, even if it does run better.
Just because your current physics representation is okay, it doesn't mean you have to sacrifice the feel of it just because you change it to be cheaper.
If you don't do something, then you will have to kiss the 3G S goodbye as target and probably iPad I
Is it 12 boxes to simulate 12 wheels? Probably your truck would have this many wheels, but I'd suggest halving it.

You should profile the iPad, you might feel it's okay, but on inspection you might find that this is still the greatest part of your frame time.

You're quite right - you're bottleneck is not rendering, it's your physics model. Start there.

I don't know, but I imagine that with a mesh collider with 1400 triangles, each face or edge of each cube will need to compare with each triangle of your meshes, potentially every physics update.

If you take the geometry for your 'track' and simply subdivide it, it will be easier for Unity to discard collision models as your truck will not interact with them. If your collision model is a whole model, then chop it up so it doesn't all need to be considered.

If you have Unity Pro, profile the game on the device. Is the spike in the physics, or are you doing lots of allocations in your collision handling methods causing lots of GC. If the latter, then this might account for a lot of your performance issues and physics may not be quite the problem it appears to be (which isn't to say you can't make it more efficient of course). In the Unity Profiler you will see what CPU time you're spending in physics as well as which methods are spiking and when and for how long you are doing GC.