I am within 6 weeks of launching my first iPhone/iPad Universal game. I've worked on it for 3 months full-time, and it is really looking great! The game runs fantastically well on an iPhone 3GS and an iPad2, but horrendously on an iPhone 4 and iPad 1. I am still relatively unfamiliar with Apple's instrument tools, but I understand that at least one or two of them could provide me with a lot more information as to what the bottleneck (particularly on that hardware) is. If I disable retina on the iPhone 4, its performance is as good as the 3GS. With the iPad 1, of course, I have no such option.

So here's my first question: what tool(s) should I run for profiling in instruments, and what should I look for to know where to optimize? I have a strong feeling there has to be some dead give-away here I'm missing that would tell me "ah, you're maxing out the GPU's fill rate", or something.

Below are some additional specifics that may help provide an idea of what I'm doing. Any help or suggestions would be truly appreciated. I will keep trying, but any pointers from folks who've been there would be tremendous. Thank you for your time and consideration! If I can leave any more details or info, just ask. Happy to provide more.
--------------


I've done a number of tweaks already, but they have either not helped or made it worse. Here's some basic info about the engine:

1) I'm using OpenGLES 2.0 (also have built the engine up to support 1.1 as a fallback)
2) It's a fully 3D game with a sprite mapping text class and standard 2D sprite support for UI
3) I'm using the PVR format for textures and sprites - all textures are 1024x1024 on iPad, and 512x512 for iPhone/iPod touch. Reducing textures to 512x512 did not help the iPad 1.
4) I'm using the POD format for 3D models - single mesh
5) I am utilizing a View Frustum Culling algorithm to prevent drawing objects not in view
6) I'm utilizing backface culling
7) My shader is not too complex and is primarily based on two direction lights
8) I was originally using GL_FLOAT for drawing primitives, but I have switched to GL_SHORT. I read somewhere on Stack Overflow that this resulted in a 30% frame rate boost for several iPhone 3D games, but mine saw no such boost. In fact, I'm considering that it may have reduced the overall performance (hah). If nothing else, it is certainly more annoying working with shorts with some of the more complex meshes. Plus the loss in the shader of having to convert texture coordinates from shorts to normalized floats at render time may be losing any benefit I get out of sending half the data. I did check to ensure that the data is 4-byte aligned too (it's 16 bytes total, an x, y, z, w component, normal component (x2), and texture coord component (x2).
9) Most meshes are very simple - 12 triangles make up the 3D tiles that are predominant in the game. The player's mesh is significantly more complex, but just about everything else is a fraction of that.

I am using CADisplayLink to control the update timing, and I am using an animation interval of 2, to cap the FPS at 30. Like I said, I get a smooth 30 on the 3GS and iPad 2, but a jumpy 20-24 on iPhone 4/iPad 1.

As an update, I'm looking at 11-14 FPS on an iPad 1, with a constant 30 FPS on all other devices (iPhone 3GS+, iPod+, iPad 2). I need to find a way to double the performance on an iPad 1. I'm really considering adding conditionals to the code like:

"if device == iPad 1, use lower res textures"

but I have a feeling Apple frowns on device-specific coding practices in app submission? Do they downright reject apps that do this? I know it's a bad practice in the first place, but when you're trying to make greased lightning run on what feels like a Nintendo 64, you sure don't want to have to compromise quality for the devices that are capable.

Any thoughts? Advice? Suggestions?

HeadKaze offered some advice to look through this guide from PowerVR (makers of the iPhone's GPU, among many other mobile GPUs): http://www.imgtec.com/factsheets/SDK...a.External.pdf

It got me down the right path. I added several great boosts along the way, but found and discovered a horrific bug. Details below:

[font="verdana, geneva, lucida,"]Hah, this makes me sad, but it was an easy problem. I have a list of a dozen things I could try to do (almost all of which are difficult to implement), a few of which I've done (which did result in a performance boost!). Turns out, this was the glaring omission on my part:

All game objects (2D or 3D) derive from an ABC that has a boolean "active" flag. If inactive, they don't get drawn.

This flag was not being set for one KEY sprite: the fade to black sprite that gets stretched the size of the viewport! So after a dramatic fade-in to the game, this sprite was hanging around *and being rendered* every draw call. That's 1024x768 pixels of wasted draw. Ouch!

Needless to say, adding a safety catch (if (!active || alpha == 0.0f) solved the problem quite nicely (and of course, fixing the active bug itself).

I'm now at 29-30 FPS on an iPad, and the other devices are even smoother. I'll still spend most of tomorrow adding the remaining optimizations I was considering (just good sense, plus allows me to do more).

Thank you so much HeadKaze for the great links - got me down the right path! Hope some of this discussion is helpful down the road for others scratching their heads like me![/font]