(iphone) which one is more precise timewise: performSelector:afterDelay vs NSTimer

Question

I'm doing animation with performSelector:withObject:afterDelay at 24fps.
(reason being, UIImageView doesn't support different interval between images)
When I run multiple animations simultaneously, seems like message queued by performselector takes long time to be picked up.

I am wondering NSTimer or yet another would be a better choice.

Thank you

• EDIT

I'm not doing anything besides running animation.
The selector I'm running takes up 0.0003 ish time.(almost no time)
But when I measure time between calling "performSelector" and the time the selector actually gets called, the time actually is longer than I specified with "afterDelay" or "scheduledTimerWithDuration"

I looked at instruments already but couldn't figure out what's causing the delay.
I just saw thread related(i guess thread pause/resume) activity a lot.
Maybe my below threadMain code is taking up much time?

- (void) myThreadMain
{
    NSAutoreleasePool* pool = [[NSAutoreleasePool alloc] init];

    // Add your sources or timers to the run loop and do any other setup.                                                                                                                                                                                                     
    NSRunLoop *runloop = [NSRunLoop currentRunLoop];
    [runloop addPort:[NSMachPort port] forMode:NSDefaultRunLoopMode];

    do
    {
        // Start the run loop but return after each source is handled.                                                                                                                                                                                                        
        SInt32    result = CFRunLoopRunInMode(kCFRunLoopDefaultMode, 10, YES);

    }
    while (self.isNeedToExit == false);

    [pool release];

    SYSLOG(LOG_DEBUG, "thread exiting");
}

Answer 1

Apple says:

This method [performSelector:withObject:afterDelay:] sets up a timer to perform the aSelector message on the current thread’s run loop.

So they both do the same thing. Your culprit is elsewhere.

By the way, you may want to take a peek at CADisplayLink. It's a specialized timer that fires at the same frequency as the screen refresh rate, intended specifically for what it sounds like you're trying to do.

Answer 2

Since all the selectors/methods share one CPU and one run loop (the UI run loop, unless you specify otherwise), both timers and delayed selectors will get called late if there is too much going on. You need to profile your app (instruments) to see what's taking up the time, and thus making other things late.