This article doesn't aim to present a benchmark that is representative of anyone's real world application (hopefully).
Just a little something provoked by this comment.
It doesn't answer the titular question in a useful way.
If you have any useful comparisons you would like me to link to, please leave them in the comments.
Seriously, this should not at all inform your upgrade decisions.
Our "code"
Let's run a simple test:
"use strict"
for (let i = 0; i < 10; i++) {
let arr = ["a single pickle"]
for (let i = 0; i < 25600000; i++) arr = [arr]
console.log(i)
}
Results
Let's start ridiculously far back:
$ nvm use 1 && time node scrap.js
Now using io.js v1.8.4 (npm v2.9.0)
real 0m38.984s
user 0m36.885s
sys 0m3.073s
nodejs v4: Oh yeah, an improvement!
$ nvm use 4 && time node scrap.js
Now using node v4.9.1 (npm v2.15.11)
real 0m21.040s
user 0m18.836s
sys 0m2.834s
nodejs v6:
$ nvm use 6 && time node scrap.js
Now using node v6.16.0 (npm v3.10.10)
real 0m23.870s
user 0m24.297s
sys 0m2.902s
nodejs v8: Back to v4 performance, awesome!
$ nvm use 8 && time node scrap.js
Now using node v8.15.0 (npm v6.7.0)
real 0m21.562s
user 0m23.256s
sys 0m2.839s
nodejs v9: (You'll see why this non-LTS is tested in a moment)
$ nvm use 9 && time node scrap.js
Now using node v9.11.2 (npm v5.6.0)
real 0m19.989s
user 0m21.716s
sys 0m2.990s
nodejs v10.0.0: Oh no, what happened?
$ nvm use 10.0.0 && time node scrap.js
Now using node v10.0.0 (npm v5.6.0)
real 1m14.604s
user 1m22.655s
sys 0m3.232s
nodejs v10: That's even worse!
$ nvm use 10 && time node scrap.js
Now using node v10.15.0 (npm v6.6.0)
0
<--- Last few GCs --->
e [22823:0x29e79b0] 18607 ms: Mark-sweep 1278.0 (1334.2) -> 1278.0 (1303.2) MB, 1849.1 / 0.0 ms (+ 0.0 ms in 69 steps since start of marking, biggest step 0.0 ms, walltime since start of marking 1875 ms) (average mu = 0.075, current mu = 0.052) allocati[22823:0x29e79b0] 20618 ms: Mark-sweep 1339.5 (1365.7) -> 1339.5 (1365.7) MB, 1900.1 / 0.0 ms (+ 0.0 ms in 5 steps since start of marking, biggest step 0.0 ms, walltime since start of marking 1965 ms) (average mu = 0.064, current mu = 0.055) allocatio
<--- JS stacktrace --->
==== JS stack trace =========================================
0: ExitFrame [pc: 0x39c8186dbe1d]
Security context: 0x363e2bf1e6e1 <JSObject>
1: /* anonymous */ [0x2b128b88e9f1] [/home/mihail/Documents/Development/zigbee/zcl-packet/src/scrap.js:~1] [pc=0x39c81876f729](this=0x2b128b88eb21 <Object map = 0x389f21f02571>,exports=0x2b128b88eb21 <Object map = 0x389f21f02571>,require=0x2b128b88eae1 <JSFunction require (sfi = 0x170c23bc6179)>,module=0x2b128b88ea59 <Module map = 0x389f21f50c21>,__filen...
FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
1: 0x8db900 node::Abort() [node]
2: 0x8db94c [node]
3: 0xad6c1e v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [node]
4: 0xad6e54 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [node]
5: 0xec44e2 [node]
6: 0xec45e8 v8::internal::Heap::CheckIneffectiveMarkCompact(unsigned long, double) [node]
7: 0xed06c2 v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::GCCallbackFlags) [node]
8: 0xed0ff4 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [node]
9: 0xed3c61 v8::internal::Heap::AllocateRawWithRetryOrFail(int, v8::internal::AllocationSpace, v8::internal::AllocationAlignment) [node]
10: 0xe9d0e4 v8::internal::Factory::NewFillerObject(int, bool, v8::internal::AllocationSpace) [node]
11: 0x113c9db v8::internal::Runtime_AllocateInTargetSpace(int, v8::internal::Object**, v8::internal::Isolate*) [node]
12: 0x39c8186dbe1d
Aborted (core dumped)
real 0m22.973s
user 0m25.113s
sys 0m0.655s
Same, but after reducing array depth to 25500000: Noticeably slower than v10.0.0, even with less work to do!
$ nvm use 10 && time node scrap.js
Now using node v10.15.0 (npm v6.6.0)
real 1m49.499s
user 2m0.444s
sys 0m3.553s
Bumping it back up to 25600000, nodejs v11: Well, at least it didn't crash
$ nvm use 11 && time node scrap.js
Now using node v11.9.0 (npm v6.5.0)
real 1m52.919s
user 2m5.220s
sys 0m3.600s
Conclusion
There is no actionable conclusion. This ridiculous case, which we certainly shouldn't want the V8 or nodejs dev teams to optimize for, has significantly regressed with 10.0.0 release and isn't making signs of getting better.
Oh well. On with our lives.
Browsers
-
The provided code runs on par with or faster in Chromium 71.0.3578.98 than nodejs v4.
I don't know what to even think about that.
-
It runs faster than v10 but slower than v6 in Firefox 65.0.
Would probably run faster if I disabled it asking "a page is slowing down Firefox, would you like to stop it?" watchdog. If anyone knows what flag can do that, please tell me.
Disclaimer
This is not to be construed as advice to delay switching to nodejs v10.
My advice would be: If you catch someone using < v10 please calmly, without sacrificing professionalism, gently, nonviolently, but insistently, break their legs.
There are many usability and security implications, and this "benchmark" is in no way representative of real applications.
(There are performance improvements in both running normal code and native aspects like IO)
Top comments (4)
@qm3ster I like your advice, its hilarious.
"My advice would be: If you catch someone using < v10 please calmly, without sacrificing professionalism, gently, nonviolently, but insistently, break their legs."
What can I say? 🤷 We must always maintain professionalism.
On that note, I'm worried someone will come for my legs, because I just noticed that my jest tests take slightly longer on 10LTS than on 8LTS.
*sweating*
Yes sure, I meant to do that but did not ... now I did