How does one profile non-CPU intensive method calls in Instruments?

If I have the following method is there a way to use Instruments 4.0 to tell me that it took one second?

- (IBAction)sleepOneSecond:(id)sender 
{
    sleep(1);
}

Right now I am using this to get the desired effect:

- (IBAction)waitOneSecond:(id)sender 
{
    NSDate * startDate = [NSDate date];
    sleep(1);
    NSLog(@"%s took %lf seconds", __FUNCTION__, 
          [[NSDate date] timeIntervalSinceDate:startDate]);
}

Time Profiler and Sampler just give time 开发者_开发知识库on the CPU which does not help in this case.

With the Time Profiler Instrument, make sure it's set to "All Sample Counts" rather than "Running Sample Times" under "Sample Perspective".

The Time Profiler in Instruments is not to determine accurate timing for individual method calls, It takes periodic samples of the running application to determine where in your code the CPU was executing instructions when the sample was taken. Then it takes all of the samples and estimates how much of the total time was spent in each method or function. This is called stochastic sampling and it doesn't measure when calls begin and end. Its just an estimate of relative time spent in different parts of the code and is meant to be used to figure out what parts of your program the CPU spends most of its time so you can focus on those parts for optimization. Usually most of the time is spent in only a few methods in an inner loop somehwere and spending time optimizing code anywhere else is a waste because doubling the speed of something that only gets executed 2% of the time only makes your code 1% faster.

So something similar to what you are doing is what you will need to do if you want to know fairly accurately how long a given section of code takes to execute. Many people use some sort of macros to make it easy to take a time measurement and the beginning and ending, computing the difference and logging it or saving up the times from multiple times through that code and averaging. Of course the problem with this kind of technique is that there is some overhead involved in the measurement itself (think Heisenberg). You can minimize this by taking before and after measurements with no code in between and subtracting this overhead number from subsequent measurements with actual code in between your before and after calls.

To do what you are trying to do, you may also look at DTrace for an automated way.