Thanks mariocaprino, those are both good tips!

Did not realize that there were two more or less identical instruments for this... Time Profiler and CPU Sampler.[/code] CPU Sampler has slightly more documentation, but Time Profiler says this:

Quote:Time Profiler gathers backtrace data in the same manner as Shark, from kernel space. Sampler, on the other hand, gathers data from user space. Consequently, Time Profiler is more efficient than Sampler at gathering data.

Though Timer Profiler was also stuck at a lousy 1ms sampling rate. The deferred display is an interesting option. It certainly removes much of the profiling cost, and it also magically reduces the the sampling rate of the Time Profiler instrument to a useful 40 microseconds. (This does not appear to be documented)

On a different project, I'm consistently getting source level profiling. No clue why, Shark was often cranky about this too, so maybe it's not surprising.

I think I got an attempt at raster bar timings working.
As long as the bar represents 'roughly' the time taken i.e. when it reaches the bottom of the screen I frame out - then this is good enough.
Not 100% certain my timing method conversion (based on the post earlier and using the machbase method) is right.

Cheers

Seem to have some 'funny' timing issues with my fake raster approach.
The timing bar can double for no apparent reason!; could be just the iphone OS "doing things" but it's a bit worrying.
I even diconnected the device from mac to check that polling etc. wasn't confusing the issue.
But it's not :-(((

I simply get the delta from start-end time then size=(size*100000.0f); being size to draw rectangle.
I must be missing something.......


Cheers

Are you dropping a frame and making the app wait until the next vbl sync, doubling the frame's time?

Hmmmm,, don't think so.
In my main loop I just:

start_timing_bar()

do something....

stop_timing_bar()

draw_barss();

then back into eagleview for all the usual.

Even doing this:

START_TIMING_BAR(0xff0000ff);


for(int k=0;k<100000;k++)
{
int f=1;
}

STOP_TIMING_BAR;

DRAW_TIMING_BAR;


Can result in massive timing differences i.e. sometimes the apparent time can double!!!; but why???????????????

Cheers

If it's exactly doubling, I would be willing to bet that it's because you are dropping a frame. V-sync is always on on the iPhone and can't be turned off.

Even if your code isn't doing anything complicated, the OS might be suspending your process long enough to cause it to drop a frame.

Oh man! :-(
The only way to make it "work" would be to sample then rather than try and draw per frame.
I suppose by 'averaging' it I could still get pretty good results. :-///?

It's not always double; but yes sometimes as high as that. Which worries me when doing a vertex build for a draw and one update it's taking half the frame and the next your over the frame!!! <Gulp!>; even if everything is static!!!!