On Surfin’ Safari David Hyatt recently posted on the topic of Background Music. One of the tidbits from that post - which really has only tangential coverage of background music - reads as follows:

Some Web pages specify repeating timers with an extremely small timeout. In fact they often use the value 0 to mean “Fire as soon as you can.� Safari 2 does not throttle these timeouts, and so a poorly-constructed page that specifies a repeating timer under 10ms will actually hog a lot of CPU. Aggressive timers were actually a problem in Mozilla for a long time before being fixed, and they are currently a problem in Safari 2. WinIE, Firefox, and WebKit nightlies basically error-correct the badly constructed page and ignore timer values of < 10ms by changing them to be 10ms. I suspect the root cause of the issue above is just that one of the pages is hogging the CPU with an aggressive repeating timer, but I am prepared to be surprised. :)

Now, I suppose this isn’t general knowledge, but it’s been this way since Netscape 2: JavaScript timers have a resolution depending on the resolution of the OS timer APIs, unless the browser provides it’s own timer implementation. That means it can vary greatly depending on not on only which browser is used, but also on which OS version is being used. Windows in particular has pretty bad resolution on timers. On Windows 9x/ME, the timer resolution is 55ms. On single processor, single core Windows NT based systems the timer resolution is 10ms. On multicore, multiprocessor or hyperthreaded processors it’s slightly higher being 14ms on the dual core I tried it on and from what data I found in a quick search 14-16ms for dual processor systems and hyperthreaded systems as well. (I couldn’t find any data for systems with 4 or more logical or physical cores.)

This means the lowest timer value that can be of any use on Windows systems is 10ms, and the lowest timer value that you can rely on is 55ms. In the *NIX world the timer resolution varies between different *NIXes and distributions, common resolutions being 10ms in BSDs and older Linux distros, 4ms in SuSE and 1ms in newer Linux distros. Mac OS X has 1ms resolution, I believe.

As an effect of the Windows timer resolution, time values less than 10ms aren’t a good idea because you won’t ever achieve those values. Worse, if looping using a timer value less than 10ms, a Windows system will pass through fewer loop iterations than the systems with better resolution, so the same code on these systems may eat considerably more CPU time and processing power. The lesson to learn: Always use 10ms or more if you use timer looping.

Posted in Javascript |

You can follow any responses to this entry through the RSS 2.0 feed. You can skip to the end and leave a response. Pinging is currently not allowed.