Tests to find the most precise and efficient timer.

• Timer: Foundation's simple Timer
• Dispatch: Dispatch Framework. main, dedicated and global queue with different qos. (asyncAfter)
• TPP: Michael Tyson's TPPreciseTimer
• Test: Some of my changes based on TPP
• Precise Timer: My Timer that uses Foundation's simple Thread
• Precise Timer2: My Timer that uses pthreads

• Mach Absolute Time explanation
• Mach Scheduling and Thread Interfaces
• thread_policy.h with some explanations for certain structs

1000 samples were taken per method. 1 sample is the difference between expected time and the actual time the timer fired. Standard measures were calculated like standard deviation, mean, mean square, min and max. Every method was tested for its CPU usage.

For timing and waiting the mach_absolute_time() and mach_wait_until() functions were used respectively. They are part of the most precise and low level API recommended by Apple, see Resources above.

Furthermore high precision Timers/Threads are also recommended by Apple, for multimedia Apps or games. Basically everything that needs accurate timing. Methods that use such a Thread are marked as high, also see the Legende below.

• main: Main Dispatch Queue
• default: Default qos for Dispatch Queues
• userInitiated: Higher priority qos for Dispatch Queues
• spin X: Spinlock with X seconds
• ratio X: Only spinlock up to X times
• prio X: Thread priority
• high: A high precision pthread

My personal goal was to make a timer that is more precise than the Core Video's CVDisplayLink and its callback, to make display timing more precise (the reason why a 60Hz period was used for the tests). From personal tests the DisplayLink timings are most similar to a default priority Thread, eg the statistics to TPP, Precise Timer and Precise Timer2 (without anything special done), because of that anything worse than those results can be safely discarded. With that being said, any mean discrepancy higher than 0.5 is regarded completely useless and anything higher than 0.1 is less useful. Only means below 0.1 are considered good enough. Furthermore, the same hold true for the standard deviation. Which only leaves us with 7 possible methods/combinations.

This basically renders the standard Timer and the Dispatch Queue completely useless, since they worsen the de facto standard.

Another criteria to chose a proper method is the CPU usage. All the plain spinlock ones generate a significant amount if CPU usage. They range from 6 times to up to 213 times of the usual amount, TPP (spin 0.1) (85.4%), TPP (spin 0.01) (47.42%) and TPP (spin 0.001) (2.42%). I consider these method not too useful due to that. Though one has to mention, if you really need a very precise timer a spinlock of 0.01 seconds has the very best accuracy with a relative mild CPU usage. The spinlock method were a bit refined by adding an upper limit of how many loops it does at max (10 times). This reduced the CPU usage significantly but also decreased its accuracy. They are just a little bit more accurate than the high priority Threads, which is might be just a natural fluctuation in the measurement.

This only leaves us with the high priority Timers, which use the least amount of CPU and are still very accurate, around 10 times as accurate.

There are also one weird observation i made.

The Dispatch Queue has one weird quirk. When only one dispatch queue is doing work and several timely close events are being queued, those events are grouped depending on the idle time. This makes the Dispatch Queue even more useless, even though i could work around it.

I found that problem after i looked at the weird statistics that were returned by my tests. Below the first image shows a weird saw pattern of the discrepancy that was measured between expected and actual time. The second image shows the expected event time (blue) and when the timer fired (orange). The longer an event is idling in the queue the more timely close events are being grouped together and fire at similar times. Very undesirable behaviour for my use cases.

Not too important, though i am still adding the plotted graphs of the different methods.

Attached is the excel file with the statistics and the graphs.