Shark is a pretty badass profiler. I don’t know much about the mach internals that let it do it’s thing, but it’s pretty sweet.
I’ve been trying to get a handle on the performance of my python-based scripting engine in the audio thread, and have found setting sign posts extremely useful for a system trace. A system trace provides a timeline view of all the threads in your app or system, and you can use sign posts to display when a particular event is happening. If I set start and end signposts around the script execution phase, I can see just how much of the audio period the script engine is taking up. This is huge.
|Shark System Trace. The Audio thread is second from the top.|
The above is a screenshot of a system trace of about 5ms, indicating a timeline of each thread in my audio application. The gui thread is at the top, the audio thread is second from the top, and the rest are disk streaming threads, watchdogs, etc.
The 5ms of execution shown above is a particularly busy audio buffer period, where the scripting engine is really close to causing an overrun and high cpu usage (and scratchy audio). The first set yellow line and green telephones indicate the previous audio period. Then the next audio period starts with a yellow warning sign post marking the beginning of script execution, and each blue telephone is a system call to release or acquire a semaphore (semaphore_wait and semaphore_signal). Then you can see it barely finishing before the next audio buffer, marked by yet another yellow line.
Whew! That was a lot of effort. Anyway, sign posts rule.