Figure 1: Chrome 20 and Firefox 12 have high resolution, scalable and consistent timer implementations
Most mobile devices we tested had timers set at 10ms resolution. This was the case for the vast majority of Android devices, as well as devices running iOS3 and iOS4. Chrome for Android and iOS5 had faster timers: their timer resolution was 4ms. And the Blackberry Playbook 2 had the slowest timer: approximately 17ms. One outlier for the Android browser was the Motorola Droid 2 Global which had a timer resolution of 16ms. Finally, when we ran the timer test on our “straight-from-Google-IO” Nexus 7 tablet running Android 4.1 and Chrome for Android, we got an odd result which showed the timer whipsawing from 4ms to 10ms. (This may due to some webkit behavior that backs the timer off to 10ms, if it’s already processing a timer callback, but would love to see if anyone from the Chrome team has insight on this.)
In other words, the most recent devices running Android 4, Chrome for Android and iOS5 have desktop-class timer resolutions, while older Androids and RIM devices have timers that are 2x to 4x coarser grained.
Timer Consistency and Scalability
Next we looked at the variability of the timer measurements at various levels of timer concurrency and stack depth. The ideal performance result is a horizontal line at the y coordinate of the timer resolution—whatever that is. Here the results were a little varied.
Our star performers were the iPhone and iPad2 (below left), as well as the Motorola Xoom running the stock Android ICS browser (below right). Each were highly consistent at their respective timer resolutions of 4ms and 10ms, with no deterioration as the number of timers increased, and just one or two spikes. Other notable performers were Chrome for Android on the Motorola Xoom and one of our Samsung Android 2.3 devices.
More typical, however was a drift of anywhere from -5ms to +10ms around the expected timer resolution, particularly when the number of concurrent timers exceeded 8. This was true across all Android handset makers and all versions of Android 2. The typical result from an Android 2.x device looked something the example below—in this case, a Samsung phone running Android 2.3.5.
Finally our worst performing devices. Surprisingly, one of these was from Apple. While all our iPods had noisy performance graphs, our iPod/iOS5 was particularly poor—with a few spikes that were literally off the chart. We also found the Playbook 2 timer to be extremely noisy, regularly spiking to 2x the 18ms timer resolution.
Lessons learned and conclusions drawn
Our survey of mobile timers shows mostly good news. The most recent mobile browsers on Android—both stock Android and Chrome for Android now have desktop quality timers. Surprisingly, it doesn’t look like Apple is taking particular care to achieve good performance on the iPod browser. For highest performance on iOS, this probably means it’s best to stick with GPU-accelerated 3D transforms for the moment. It also reiterates the need for wide adoption of the work-in-progress animation timing spec.
Martin de Keijzer says
This sounds all so familiar, I’ve been using the mobile web as a platform for over a year now. And within that year I’ve seen many performance gains, especially in animation. But there is definitely still work to be done on that side.
Luckily Google finally did the right thing and released Chrome for Android. Apple could also push things ahead a lot further, I wonder why they’re holding back. The worst part on the Android side is the (feature) phones which are not able to upgrade, even device manufacturers like Samsung and HTC don’t put enough effort in keeping their devices up to date in my opinion.