Curious. Although the point stands, mine difference is ~4 times smaller:

real 0m0.650s
user 0m0.492s
sys 0m0.072s

real 0m5.374s
user 0m5.028s
sys 0m0.412s

That's interesting. I bet intervals just got faster - I ran my tests at a pretty old version of node. Too bad I didn't specify it (I don't actually remember it right now).

0.6.8 here. :)

$ time node nextTick.js

real 0m0.534s
user 0m0.467s
sys 0m0.069s

$ time node setTimeout.js

real 0m10.724s
user 0m10.163s
sys 0m0.678s

on my 13" Air

Intel(R) Core(TM)2 Duo CPU E7400 @ 2.80GHz
node v0.6.17

$ time node nextTick.js

real 0m0.622s
user 0m0.532s
sys 0m0.084s

$ time node timeOut.js

real 0m11.111s
user 0m10.273s
sys 0m0.636s

node nextTick.js 3.11s user 0.24s system 93% cpu 3.587 total
node setTimeout.js 31.21s user 1.59s system 89% cpu 36.616 total

This kills the Atom processor.

$ uname -a
Darwin MacBook-Air-13.local 11.4.0 Darwin Kernel Version 11.4.0: Mon Apr  9 19:32:15 PDT 2012; root:xnu-1699.26.8~1/RELEASE_X86_64 x86_64

$ node -v
v0.8.0

$ time node nextTick.js 
real   0m0.833s
user   0m0.714s
sys    0m0.117s

$ time node setTimeout.js 
real   0m2.600s
user   0m2.312s
sys    0m0.211s

intel core i5 @2.4 GHZ

$ node -v
v0.8.2

for (var i = 0; i < 1024 * 1024; i++) {
    process.nextTick(function () { Math.sqrt(i) } )
}

$ time node nextTick.js 
real    0m0.654s
user    0m0.576s
sys 0m0.076s

for (var i = 0; i < 1024 * 1024; i++) {
    setTimeout(function () { Math.sqrt(i) }, 0)
}

$ time node setTimeout.js 
real    0m1.740s
user    0m1.608s
sys 0m0.140s

var batch = 128;
for (var i = 0; i < 1024 * 1024; i+= batch) {
    (function(i) {
        setTimeout(function () {
            for (var j = i; j<i+batch; j += 1) {
                Math.sqrt(j)
            }
        }, 0)
    })(i);
}

$ time node setTimeoutBatch.js 
real    0m0.094s
user    0m0.084s
sys 0m0.008s

for (var i = 0; i < 1024 * 1024; i += 1) {
    Math.sqrt(i)
}

$ time node forLoop.js 
real    0m0.049s
user    0m0.044s
sys 0m0.000s

Seems that setTimeout(fn, 0) is not so bad if used more efficient.

Ugh, microbenchmarks. JIT compilers will behave differently as code paths are warmed, and will inline some loops more efficiently than others. This doesn't portend anything meaningful in a real-world application, I fear.

What's the point of doing

 for (var i=0; i<1<<20; i++)
      async(function() { Math.sqrt(1<<20); });

Seems someone has forgotten a closure, to extract a root from very many integers you would do

 for (var i=0; i<1<<20; i++)
       async( Math.sqrt.bind(Math, i) );

$ uname -a
Linux ### 3.5.0-26-generic #42-Ubuntu SMP Fri Mar 8 23:18:20 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

$ node -v
v0.8.22
$ time node nextTick.js

real 0m0.787s
user 0m0.704s
sys 0m0.088s
$ time node setTimeout.js

real 0m2.874s
user 0m2.708s
sys 0m0.208s

$ uname -a
Darwin Lourenzo-Mac-Mini.local 12.4.0 Darwin Kernel Version 12.4.0: Wed May 1 17:57:12 PDT 2013; root:xnu-2050.24.15~1/RELEASE_X86_64 x86_64 i386 Macmini6,1 Darwin

$ node -v
v0.10.15

$ time node nextTick.js

real 0m0.650s
user 0m0.505s
sys 0m0.074s

$ time node setTimeout.js

real 0m1.067s
user 0m0.985s
sys 0m0.086s

"setTimeout" usually has built-in minimal delay value (which is a few ms). Even if you call "setTimeout" with 0 ms delay it will still run with at least with few ms delay. This is an another reason why it is so slow in these "benchmarks".

See: https://developer.mozilla.org/en/docs/Web/API/window.setTimeout#Notes