Question

I am trying to resolve UI issues surrounding NSTimer/NSOperationQueue performing inconsistently. I am seeing that regardless of whether I use NSTimer or NSInvocationOperation to trigger the code below, many times the performance is as needed, but several times the behaviour is slow (and as in the example below, the code runs for well over 1 sec sometimes).

Here is my code as invoked via NSInvocationOperation:

-(void) progressAsynch{
    for (count = 1; count<=100; count++) {

        // Reposition Label's CGRect.
        [self performSelectorOnMainThread:@selector(moveLabelToNewPosition) withObject:nil waitUntilDone:YES];

        //Update the progress of the progress view
        [self performSelectorOnMainThread:@selector(advanceProgressViewProgress) withObject:nil waitUntilDone:YES];

        //Sleep for 10 millisecs
        [NSThread sleepForTimeInterval:0.01];

        //if the progress view has progressed fully call main thread to to next tasks.
        if(progressView.progress == 1) {
            [self performSelectorOnMainThread:@selector(processResult) withObject:nil waitUntilDone:YES];
        }
    }

}

The code of the method invoked by the NSTimer( triggering every 10 ms) is very similar to the above, just that it would not have the for loop in it.

Evidently, it appears that there is something outside of this processing that is slowing this performance every so often.

Curious to know if you’ve into similar issues, or if you have any pointers/tidbits that might help me out.

Thanks in advance..

Answer 1

Inter-thread communication is not that fast, and waitUntilDone:YES adds additional thread-synchronization overheads and is completely unnecessary (I’m pretty sure performSelectors are serialized). You might have better luck doing something like

-(void) progressAsynch{
    for (count = 1; count<=100; count++) {
        [self performSelectorOnMainThread:@selector(stuff) withObject:nil waitUntilDone:NO];
        [NSThread sleepForTimeInterval:0.01];
    }
}

However, this is still bad. It looks like self is a view or view controller which will be retained by the NSInvocation, and presumably released on the background thread. Most of UIKit is not thread-safe; the Game Center example code goes to great lengths to state that UIKit classes should not even be released on background threads, because the release might cause a -dealloc, which in UIKit classes might not be thread-safe. (Ouch.)

(Also note that your call to progressView.progress is not safe from a background thread.)

You’re also at the limit of what’s possible: I’m pretty sure that iOS timeslicing is 10 ms, which means that if anything else needs the CPU at any point (and there are a lot of background processes; try using Activity Monitor in Instruments sometime) your animation might appear to lag.

Finally, with some audio-playing code, we’ve noticed that NSTimer is not very accurate. I’m not sure why. I think we fixed it with something that used SIGALRM (and code which probably wasn’t signal-safe, sigh).

You might have better luck with CADisplayLink, which is synced with the refresh rate of the display (I think you pass it [UIScreen mainScreen]) and designed to be used by animations, so it should perform a bit better. iOS 3.1+, but I suspect there’s little point supporting 3.0.