Now that I have bombs dropping, splosions and all sorts of good stuff happening, my framerate on the device has started to drop. Time to whip out the good ole profiler I thought. Well I gave it a try but shark was greyed out and when I tried the cpu profiler option, it launched instruments but my app would not launch(using go with <insert profiler tool here>). Is there something special I have to enable to use shark? I was in debug mode, and I can debug standalone no problem.

You have to start it from Shark in Sampling>Network/iPhone profiling. Do be forewarned that it takes *forever* for it to analyze the samples. I typically stick to just a few seconds of sampling, which seems to take less time.

I got shark to work, thanks!
I noticed the top cpu user was objc_msgSend, under that is some of my code. Is that normal? Just checking based on the link below and past experience I wouldn't have assumed that. I am going with the theory that the first thing under objc_msgSend is the real culprit.

Thanks.

http://developer.apple.com/tools/shark-s...indow.html

I'm no Shark expert, but my top 2 symbols are:
ures_getByKeyWithFallback (3.7%, with none of my methods underneath it)
objc_msgSend (2.7%, with various methods underneath that)

This is my collision detection so it was sorta expected, but the funny thing is this function on the top (well under the objc one) is the main loop of that, but shouldn't it be showing the time in all the actual worker functions. This guy doesnt do all the math. Granted it will hang out here a long time since this is the loop.

Another odd thing, my rendering shows .8%, not too high but still semi near the top. However the class at the top of that stack has like 6 lines in the function its showing. Those lines call functions which are doing all the work, but still why wouldn't it show the actual function doing the work?

Ouch and finally, szone_free is using 4.2% of cpu originating from my code on a line that is just doing conformsToProtocol. Is that really that slow? That's ridiculous. I wonder why that function call is even mallocing and freeing anyhow.

found an alternative to conformsToProtocol
You would declare an enum somewhere with the class hierarchy options. Then in your base class you put some function like -(bool)instanceOf:(TypesEnum)type;
By default unless type is the top class it returns false. Then each subclass that implements an interface overrides that and does a if(type==MyInterface)return true, else return [super instanceOf:type]; sorta deal
Sounds kinda kludgy though so before I go about doing that does anyone have a better suggestion?

After some more reading I think, you can switch shark into top down mode which provides the actual call flow for performance reading. The default mode shows function usage independent of where it came from.

After removing conformsToProtocol and doing the enum solution performance went way up. Now I am looking into other areas. One I found is the following:
When something moves, it loops across all other things in the game. This is for collision detection. First it filters out anyone who fits some easy categories(too far, game rules prevent collision), then it finally does some actual collision detection. The interesting thing here is that when i double click on this class and look at the lines of code i can see % usage on each line. Now assuming those percents are supposed to sum to 100 and they represent the enitre classes usage, whats interesting is that 30%(the highest) usage is on the actual for loop itself. I am using the for(id i in things) fast enumerator which I was under the impression was fast. So should it really be using 30% of my time just doing the itteration across the loop, or does this time include all the time spent in the loop as well? Its an NSArray if that matters.
Thanks in advance for any input

Update: changing this throughout my code to use just a regular *to a obj c object and then pass the size made a big different. NSArrays must be pretty slow. Also removing self. anywhere you don't really need it is huge.

If you are concerned about performance ... use std:vector ... safer and more convenient than what you are doing right now.

Believe me .. sooner or later, passing pointers with size will result in a nasty hard-to-track bug :-)

Been doing tuning on this and I noticed something odd that maybe somebody can shed some light on.
While using shark and double clicking to see the cpu usage on each line of code, I noticed that the code it shows doesn't match my code. I made a change and went to this screen to see the impact, but the new lines of code I added are not there. I tried a clean too. Does anyone know where it gets this code file from? To further test this I added a printf. I see the spam, I see the performance hit from having this in a heavy traffic place. There is no printf in the file. I do notice that the file did change a bit, it looks somewhat messed up now