iPhone Unity internal profiler assistance

Hello and thanks for your attention.

I'm now at a point in my project where I need to make some decisions regarding which way to procede technically. To do so I would like to see what kind of impact my current implementations have via the iPhone Unity internal profiler. I have it turned on now in Xcode but it's output is a little bit confusing. Here is what I'm seeing:


iPhone Unity internal profiler stats:

cpu-player- min: 14.9 max: 102.2 avg: 42.3

cpu-ogles-drv- min: 2.0 max: 18.5 avg: 5.0

cpu-present- min: 1.1 max: 12.0 avg: 2.5

frametime- min: 35.1 max: 126.8 avg: 57.1

draw-call #- min: 17 max: 17 avg: 17 | batched: 16

tris #- min: 7559 max: 7559 avg: 7559 | batched: 3848

verts #- min: 3925 max: 3925 avg: 3925 | batched: 1936

player-detail- physx: 12.6 animation: 0.0 culling 1.4 skinning: 0.0 batching: 1.9

render: 17.3 fixed-update-count: 1 … 7

mono-scripts- update: 2.2 fixedUpdate: 2.6 coroutines: 1.8

mono-memory- used heap: 253952 allocated heap: 266240 max number of collections: 1 collection total duration: 16.6


Simple descriptions of the different values with reasonable targets (if targets can be defined for a top down 2D type of game) would be very helpful

On top of that what I need to know is which GO's in my game are slow or unreasonable. I don't see how to connect the data with things happening in game other than just watching and hoping to see unreasonable spikes in realtime, with my eyes. :) There has to be a better way. :)

Thanks, --Goody!

cpu-player the amount of CPU processing time (in ms) used by your app (so doesn't count CPU used by OS for background tasks and stuff)

cpu-ogles-drv time spend in the openGL-ES driver

frametime the total time for processing a frame (so basically the time between two updates)

draw-call number of draw-calls made to the GPU (something that shouldn't really get much higher than 30 or your app will be slow), batched how many drawcalls are eliminated by combining the mesh and send them together (if you have lots of small meshes sharing material Unity will send them over combined as one mesh) tris triangles per frame

verts points per frame

physx time used by physics engine (collisions, rigidbody movements, etc)

animation time used by animation engine (calculate new bone positions)

culling time spend to remove objects from pipeline that are outside view

skinning time (time to calculate new mesh from bone possition (i think))

batching the process of combining meshes to save drawcalls (nothing is for free :-)

render the time the render pipeline needs to do the actual rendering

update time unity spend in Update functions of your scripts

fixed-update time unity spend in FixedUpdate functions

coroutines time spend in all your coroutines

used heap memory used

allocated heap memory claimed by app

nr of collections #times garbage collector cleans up

duration the time garbage collector spend on cleanup

The biggest issue seems to be you've got some spikes (at least in this measurement), do you see them often or is this a measurement just after startup and is Unity loading in assets using for first time in scene?

The amount if tris is quite high, so you seem to have a complex scene or you need to simplify models. Measurement doesn't say much, look at the flow, do spikes happen often, try to relate to what's happening in your game. There isn't really much deep profiling so you have to do with those limited tools. You can of course do a bit of measurement yourself by calculating the time diff between entrance and exit of difficult code blocks. Try to keep draw calls as low as possible, share textures and materials. But there should be some good performance docs on the web so won't name them all here.

Close to line 568 (could have shifted a bit after modifications I made) in AppController.mm you find a `const int EachNthFrame = 30`. It can be useful to increase this a bit to give a better general feel about performance (as the default 30 frames is quite short to get a meaningful average). Hope this helps a bit.

The other thing I needed to know was what the numbers basically meant.

My understanding of it now is that each of the values represent how many milliseconds each value are costing and that you don't want them to total up above 60 or so if you want to maintain 30fps. The ones that are spiking high are the ones to generally worry about. I'm still not sure what good baselines for each are though.

Oh yeah, and, the best way I know to see what gos are causeing spikes is to put in special debug.log messages in the scripts when things are happening. They show up in the Xcode log file. Make sure to turn off collapse in the unity log otherwise it omits duplicate entries.