In browsers, if you use setTimeout
from within a function called by setTimeout
then a minimum delay of 4ms will be enforced. Mozilla\'s developer w
It should be noted that timer implementation will vary by operating system. For example, I remember a "good old" JTimer issue where the resolution of the timer was 16ms on Windows, and ~1ms on other platforms. It is almost certainly worth testing on your particular server.
From this test, it doesn't seem that it does have a minimum delay.
If you do a setTimeout()
that has a 10ms
duration, and long the return value to the console, this is what you get:
var timer = setTimeout(function(){ console.log(timer);}, 10);
{ _idleTimeout: 10,
_onTimeout: [Function],
_idlePrev: null,
_idleNext: null,
_idleStart: Sun, 28 Aug 2011 14:34:41 GMT }
Similarly, with a 1ms
duration, you get:
var timer = setTimeout(function(){ console.log(timer);}, 1);
{ _idleTimeout: 1,
_onTimeout: [Function],
_idlePrev: null,
_idleNext: null,
_idleStart: Sun, 28 Aug 2011 14:34:59 GMT }
But if you do a 0
duration, you don't get an _idleTimeout:
property at all, which would seem to suggest that the callback is invoked immediately, though asynchronously.
var timer = setTimeout(function(){ console.log(timer);}, 0);
{ repeat: 0, callback: [Function] }
Furthermore, if I do simple start/end date comparison, I usually get 0
as the result of subtracting the start from the end.
var start = Date.now();
var timer = setTimeout(function(){ console.log(timer, Date.now() - start );}, 0);
{ repeat: 0, callback: [Function] } 0
These tests were done using Node.js 0.5.2
.
It doesn't have a minimum delay and this is actually a compatibility issue between browsers and node. Timers are completely unspecified in JavaScript (it's a DOM specification which has no use in Node and isn't even followed by browsers anyway) and node implements them simply due to how fundamental they've been in JavaScript's history and how irreplaceable they are otherwise.
Node uses libuv which a cross-platform abstraction layer for lower level system things like file-system, networking stuff, etc. One of those things is timers, which Node provides a minimal wrapper around. At the libuv level, the timers used are the system-specific high precision timers. In Windows, for example, this is implemented using QueryPerformanceFrequency
and FileTimeToSystemTime
which provides resolution measured in nanoseconds.
In Node, if you specify setTimeout(callback, 1)
then it will be executed one millisecond later (assuming the system doesn't delay it due to be overwhelmed). In browsers, the minimum time will be 4 milliseconds as specified by the HTML5 spec: https://developer.mozilla.org/en/DOM/window.setTimeout. This isn't a guaranteed time, just a minimum. Most browsers can be expected to have a ~15ms resolution which impacts DOM animations.
One valid piece of info is that timeouts set to the same millisecond, during the same frame, will be executed in the order they were queued. If you were to do:
setTimeout(callback1, 1);
setTimeout(callback2, 1);
setTimeout(callback3, 1);
setTimeout(callback4, 1);
All in one block, Node should call them in that order. This only applies if they have the exact same resolution time.
http://msdn.microsoft.com/en-us/library/windows/desktop/ms644905(v=vs.85).aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/ms724280(v=vs.85).aspx