$ time node nextTick.js
real 0m0.344s
user 0m0.276s
sys 0m0.067s
$ time node setTimeout.js
real 0m9.125s
user 0m8.707s
sys 0m0.410s
Feel free to fork and add your results!
for (var i = 0; i < 1024 * 1024; i++) { | |
process.nextTick(function () { Math.sqrt(i) } ) | |
} |
for (var i = 0; i < 1024 * 1024; i++) { | |
setTimeout(function () { Math.sqrt(i) }, 0) | |
} |
RAM 3.7 GiB
Processor Intel® Core™ i5-2467M CPU @ 1.60GHz × 4
Arch 64-bit
OS Linux, Ubuntu 13.10
$ time node nextTick.js
real 0m0.749s
user 0m0.630s
sys 0m0.089s
$ time node setTimeout.js
real 0m1.294s
user 0m1.223s
sys 0m0.080s
RAM: 4 GiB
Proc: [email protected]
OS: Win 7x64
$ time node benchmark/nextTick.js
real 0m0.843s +/- 0.078
user 0m0.015s
sys 0m0.016s
$ time node benchmark/setTimeout.js
real 0m1.468s +/- 0.048
user 0m0.000s
sys 0m0.015s
Ubuntu-14.04
node -v: v0.10.35
$ time node nextTick.js
0.42s user 0.04s system 99% cpu 0.465 total
$ time node setTimeout.js
1.08s user 0.23s system 100% cpu 1.306 total
😄 👍
$ time node nextTick.js && time node setTimeout.js
real 0m1.044s
user 0m0.933s
sys 0m0.120s
real 0m1.499s
user 0m1.420s
sys 0m0.117s
Meh.
Can someone explain why there is a difference? In fact, I am facing an issue where setTimeout(f, 0)
and process.nextTick(f)
behave entirely different. Within a loop, the first will work as expected, whilst the second appears to not work.
Ubuntu 15.10 (VMWare player)
6 cpu | E5-1650 @ 3.2
Node 5.0.0
Average results after 3 runs
(With other node processes opened)
$ time node nextTick.js
real 0m0.924s
user 0m0.584s
sys 0m0.348s
$ time node setTimeout.js
real 0m0.732s
user 0m0.608s
sys 0m0.124s
(No ther node processes opened)
$ time node nextTick.js
real 0m0.800s
user 0m0.736s
sys 0m0.072s
$ time node setTimeout.js
real 0m0.714s
user 0m0.644s
sys 0m0.076s
I think you must compare setTimeout(fn, 0)
to setImmediate(fn)
, but I think setImmediate
will be still a bit faster.
$ uname -a
Darwin Wind.local 15.4.0 Darwin Kernel Version 15.4.0: Fri Feb 26 22:08:05 PST 2016; root:xnu-3248.40.184~3/RELEASE_X86_64 x86_64
$ node -v
v5.0.0
$ time node nextTick.js
real 0m0.761s
user 0m0.691s
sys 0m0.075s
$ time node setTimeout.js
real 0m0.728s
user 0m0.657s
sys 0m0.074s
$ time node setImmediate.js
real 0m0.682s
user 0m0.621s
sys 0m0.064s
@ismoura No much difference right?
$ uname -a
Linux 4.7.0-040700-generic #201608021801 SMP Tue Aug 2 22:03:09 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
$ lsb_release -a
Distributor ID: Ubuntu
Description: Ubuntu 16.04.1 LTS
Release: 16.04
Codename: xenial
$ node -v
v6.4.0
$ time node nextTick.js
real 0m2.449s
user 0m2.252s
sys 0m0.124s
$ time node setTimeout.js
real 0m2.693s
user 0m1.604s
sys 0m0.156s
Using let
$ time node nextTick.js
real 0m2.875s
user 0m2.768s
sys 0m0.156s
$ time node setTimeout.js
real 0m2.305s
user 0m2.128s
sys 0m0.108s
Using var
$ time node nextTick.js
real 0m2.300s
user 0m2.256s
sys 0m0.088s
$ time node setTimeout.js
real 0m1.699s
user 0m1.588s
sys 0m0.108s
RAM 8G
core 2
time node nexttick.js
real 0m0.863s
user 0m0.795s
sys 0m0.089s
time node timeoutqps.js
real 0m1.084s
user 0m0.978s
sys 0m0.111s
Darwin Kernel Version 16.3.0: Thu Nov 17 20:23:58 PST 2016; root:xnu-3789.31.2~1/RELEASE_X86_64 x86_64
node v7.2.0
node nextTick.js 0.62s user 0.12s system 99% cpu 0.747 total
node setTimeout.js 0.70s user 0.11s system 98% cpu 0.821 total
@IngwiePhoenix The explanation is here: https://nodejs.org/en/docs/guides/event-loop-timers-and-nexttick/#process-nexttick-vs-setimmediate
process.nextTick()
allows you to "starve" your I/O events. setImmediate
is safer.
$ uname -a
Darwin MacBook-Pro.local 18.7.0 Darwin Kernel Version 18.7.0: Tue Aug 20 16:57:14 PDT 2019; root:xnu-4903.271.2~2/RELEASE_X86_64 x86_64
$ node -v
v12.11.1
$ time node nextTick.js
node nextTick.js 0.52s user 0.12s system 189% cpu 0.338 total
$ time node setTimeout.js
node setTimeout.js 1.09s user 0.12s system 128% cpu 0.938 total
on ubuntu virtual machine
time node nextTick.js
real 0m0.669s
user 0m0.487s
sys 0m0.357s
time node setTimeout.js
real 0m1.513s
user 0m1.709s
sys 0m0.090s
400 MHz ARM926EJ-STM ARM® Thumb® Processor
32 Kbytes Data Cache, 32 Kbytes Instruction Cache, MMU
Is expected this result on arm platform?