macOS UI performance and profiling

[Sijmen]

I'm making an app with some animated content in a view. There's also a timeline with a playhead.

The playback is controlled using an NSTimer. I've tried both using a fixed 0.02s time interval and a variable interval that was calculated after the frame. The actual delta time is calculated by checking the difference in system time ([NSDate timeIntervalSinceReferenceDate]) between the previous and current frame, so I'm not relying on that 0.02s interval.

This all works great on my alu iMac. It's silk smooth.

On my PowerBook G4 though, the animation is pretty choppy. This is especally visible for the playhead, which moves at a very irregular tempo. But somehow the irregularities are regular, it's like there's a pattern. It speeds up and slows down a bit with regular intervals.

I've tried profiling with Instruments on the G4. But 80% of the time is spent in mach_msg_trap. From IRC and some Google searches I've understood that this simply is time where my app isn't doing anything and it's waiting. That seems to imply that there's no CPU bottleneck.

So what is causing the choppy playback? Is it the timer? Is it the way I find out the delta time ([NSDate timeIntervalSinceReferenceDate]) between frames? Is it somehow memory related? How do I found out?

 

[Catfish_Man]

Well, I would recommend looking into using Shark (http://developer.apple.com/tools/shark_optimize.html) rather than Instruments for performance work. However, Instruments could be useful in some other ways; for example if you can correlate lag with disk reads that might indicate that you need to fix an IO issue that isn't present with the faster disk on the iMac.

 

[Krevnik]

Just because you are spending 80% of the CPU's time waiting, doesn't mean the remaining 20% isn't poorly optimized or has some other bottleneck.

I might bring up instruments and look at disk/network IO while looking at the samples as well, see if there are any patterns.

A couple things I would check just off the top of my head:

- Log the duration you spend rendering each frame and graph it. See if it is even or uneven, and by how much. It might tell you a little information about why it has issues.
- Are you rendering this from RAM, disk, or some combination of both? How much processing do you do breaking out each frame to render it?

If you are seeing behavior that looks like it might be disk-related, try using a thread to pre-load the frame before the timer hits. This can be a thread that is woken up when its buffer is not full (semaphore or similar), does the I/O, shoves it in the buffer, and sleeps again.

If you are seeing behavior that looks like it is related to processing the frame, try doing the same. You can process, and possibly even render the frame before it is time to blit, and then just do a blit when the timer expires.

(And what Catfish_Man said, as Shark is the better tool to tell you which methods in your code is eating your active CPU time)