Is nodejs v11 faster than v6

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)

Comments

[Giorgos Kontopoulos 👀]

@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."

[Mihail Malo]

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*

[Giorgos Kontopoulos 👀]

Yes sure, I meant to do that but did not ... now I did