10 ms·

Node 8.3.0 released

172 points by binarray2000 9y ago

k__ 9y ago
Nice. Any noticeable performance gains in everyday use?
- __s 9y ago
  They link https://medium.com/the-node-js-collection/get-ready-a-new-v8-is-coming-node-js-performance-is-changing-46a63d6da4de https://medium.com/the-node-js-collection/get-ready-a-new-v8... I'm mostly glad it'll come with an updated WebAssembly, hopefully fixing this bug: https://bugs.chromium.org/p/v8/issues/detail?id=6204 https://bugs.chromium.org/p/v8/issues/detail?id=6204 which blocks Luwa from working in node (handwritten wasm has a tendency to run into things emscripten would not.. I expect the same vice versa) Will also enjoy not having to use a TextEncoder/TextDecoder shim. Kind of weird that they went full out with Unicode there, last I recall browsers were moving towards only supporting utf8
  - romanovcode 9y ago
    > write high performance JavaScript Does anyone with high performance requirements writes JS? Isn't that setting yourself up for failure on the first step?
    - jaegerpicker 9y ago
      Depends on your application and style of development. In my experience Node.js is almost always much faster than Ruby/Python and in some cases it's much faster than Java Spring type apps for certain types of network applications (mainly io bound web apps serving a lot of small requests, the event loop async nature of node really shines there). It's not C/C++ or pure Java or Go type of speed but for a lot of web application development? Node.js is great performant choice.
    - merpnderp 9y ago
      "Does anyone with high performance requirements writes [JS, Python, PHP, Ruby, Perl, Tcl, Shell, Scheme, Lua]? Isn't that setting yourself up for failure on the first step?" And yet there are a plethora of cases where all of those languages have been used with high performance requirements.
      - romanovcode 9y ago
        Yeah, that's my point. I'm not hating on JS or dynamic languages but to me it seems a stupid decision to go with that kind of language if you really need performance.
        coldtea 9y ago
        That's assuming you ONLY need performance. How about you needing performance AND web compatibility?
    - Cthulhu_ 9y ago
      Not when JS is fast enough, and if you want standards-compliant web games (like webgl), it's your only option. There's a big number of startups that used Node for their back-end, if it becomes faster without them having to rewrite their codebase, that's a win too.
    - skibz 9y ago
      > Does anyone with high performance requirements writes JS? It's possible to call into C from Node. So there's nothing stopping you from implementing performance-critical parts of a system with native code, and then invoking it from JavaScript.
      - coldtea 9y ago
        Nothing except of it being messy and you ending up with two problems (to paraphrase JWZ).
    - coldtea 9y ago
      >Does anyone with high performance requirements writes JS? Isn't that setting yourself up for failure on the first step? You assume that "high performance" is the only requirement, so that it dictates everything. People also have other requirements like "it has to run on a browser/on the web" etc AND high performance. It's not like HPC people suddenly rush to use JS. But there are people targeting the web/node etc that DO want as high performance as they can get away with (e.g. web games).
    - SOLAR_FIELDS 9y ago
      Yes, there are use cases for high performance JS. We have JS that we use client side that we also use server side for Hadoop processing of data. So we didn't want to rewrite and maintain this large codebase in both Scala/Python and JS, so we ran Node on Hadoop. No, it really isn't setting yourself up for failure if you do it correctly. Node really is quite fast; for our use case it rivaled Java 8 runtime in MR CPU time, the only downside is it had double the memory footprint. With enough hardware, memory is not too much of an issue.
    - qaq 9y ago
      Walmart, PayPal etc. are doing fine running large scale apps on node.
      - romanovcode 9y ago
        Scalability is not performance.
    - westoque 9y ago
      It depends on the context of "high performance". For example, would a 400ms load time be considered "high performance"? I always say use the best tool for the job. And this usually means getting the requirements then laying out the solutions and picking the best solution out of the bunch.
    - akmittal 9y ago
      >Does anyone with high performance requirements writes JS? It bothers me that people still think JavaScript is slow. I think JavaScript(engines) is the only languages which is getting significant performance improvement on monthly basis since V8 was introduced. It is the abstraction people in JS/Frontend world people are used to, make it seem slow.
- bricss 9y ago
  Yaasss! New pipeline of Ignition and Turbofan provides huge performance increases. Read this article -> https://v8project.blogspot.com/2017/05/launching-ignition-and-turbofan.html https://v8project.blogspot.com/2017/05/launching-ignition-an...
  - stonewhite 9y ago
    From the first chart in the link, I can't help but notice reddit is now slower with Turbofan + Ignition. It probably has something to do with a JS Dev who deeply understands how AutoCodegen works and driven the project accordingly.
    - bricss 9y ago
      I might say that some parts of code can perform differently depending on the style of source code.
- calafrax 9y ago
  I have run some very simple tests and performance is very close for real world complex apps, ~10% faster for an express hello world and ~10% slower for http stack only. Basically TF is at parity on average but slower for code like the node core that was highly optimized to the particularities of crankshaft. Hopefully npm 5.3.0 actually works since 5.0.0 was completely broken for me. v7.10.0 Test suite for real world app real 0m29.669s user 0m5.376s sys 0m0.356s v8.3.0 Test suite for real world app real 0m30.180s user 0m5.420s sys 0m0.220s v7.10.0 Express Hello World Requests per second: 6751.08 [#/sec] (mean) HTTP Hello World Requests per second: 13407.31 [#/sec] (mean) v8.3.0 Express Hello World Requests per second: 7734.33 [#/sec] (mean) HTTP Hello World Requests per second: 12601.42 [#/sec] (mean)
xori 9y ago
I wonder if this will lead to Electron using less RAM... nah.
- v0lta 9y ago
  It's the Chromium part of Electron that uses that much RAM.
  - xori 9y ago
    Yea? But only because the old V8 had Crankshaft running in parallel. New version has this disabled IIRC.
bdefore 9y ago
Shame about npm5 being significantly broken, taking the wind of the node 8 sails. https://github.com/npm/npm/issues/16991 https://github.com/npm/npm/issues/16991
- gcp 9y ago
  How does npm5 compare to yarn? I didn't notice anything, but I'm using yarn everywhere, so...
  - 0xptr 9y ago
    Speed wise npm@5 caught up a lot of ground. Iirc it was the same a while ago. However, I always felt like the release was a bit rushed. I sticked to Yarn too tho.
    - X-Istence 9y ago
      This is so completely and utterly wrong, unfortunately... Yarn takes 12 seconds to install all of our node_modules, npm@5 (latest) takes over 12 minutes. This made it completely and utterly untenable for our CI system, so we switched to yarn and shaved 12 minutes off our CI builds. It's been fantastic.
      - orf 9y ago
        That's got to be down to caching. What's the difference if the yarn cache is cleared?
        X-Istence 9y ago
        25 seconds when the yarn cache is cleared... downloading is not the slow part here. Old results from about a month ago: https://twitter.com/bertjwregeer/status/887450964420055043 https://twitter.com/bertjwregeer/status/887450964420055043 npm 5.3.0: added 1991 packages in 538.289s yarn v0.27.5: Done in 58.42s.
jnbiche 9y ago
Still disappointed that Node has backed out of optimized tailcalls (edit: should have written proper tail calls here, since that's what the past 3 now specs have called for, ES5, ES6, and ES2017). I think it's the only part they haven't implemented. I think a lot of the pushback I'm seeing against TCO comes from traditional programmers who don't like functional programming and who think that recursion shouldn't play any role in production software. I get that there are also some who have legitimate implementation concerns, but the reflexive pushback TCO gets from a lot of the V8 maintainers compared to any other new ES6 feature seems telling to me (correct me if I'm wrong here). What they don't understand is that JavaScript programmers are rapidly moving toward functional programming. Already, there's a heavy functional influence on the React community, probably the dominant frontend framework/library at the moment. Clojurescript and Elm have had an outsize influence on the JavaScript community, and I see more and more programmers using functional paradigms in their everyday code (particularly maps, filters, and reductions). I know we'd see much more recursion if it were technically feasible. Edit: Absolutely right, my critics. I brain farted on this one. It's not Node, it's V8. I did refer to this in the second paragraph, but stupidly blamed Node for it in the first paragraph. Edit 2: As I said, I shouldn't have singled out Node, particularly since it's V8 that's making this call. But my criticism was more directed toward most of the JavaScript implementers who seemed to have single-handedly decided that the es6 spec was all cool except for the one part they don't like. And I could accept the criticism that implicit tailcalls are problematic, except they seem opposed to labeled tailcalls as well. I think there are lots of implementers who simply don't believe that recursion has a place in "real" software. I've not heard these exact words from an implementers before, but I've known quite a few senior developers of my generation (40s) who have said this exact thing to me (they also can't seem to get the difference between structural and generative recursion).
- koolba 9y ago
  Does V8 handle them? If not how would we expect Node to do so?
  - jnbiche 9y ago
    You're correct, I updated my post accordingly.
Phlow 9y ago
Still can't get a debugger; statement to break... https://github.com/nodejs/node/issues/7593 https://github.com/nodejs/node/issues/7593
- erikpukinskis 9y ago
  It's amazing to me how blazé the Node community is about breaking the debugger. In other language communities that would be considered sacrilege, but in Node the response is often "meh... I just console.log everything". Transpiling, source maps, so many hacks that barely work.
sparrish 9y ago
I've been waiting for this DNS behavior change for years. Great release!
nessup 9y ago
From the Medium post about speed improvements in this version: > The size of a function, including it’s signature, the white space and even comments can affect whether the function can be inlined by V8 or not. Yes: adding a comment to your function may cause a performance hit somewhere in the range of a 10% speed reduction. Uhh... byeee
- dbbk 9y ago
  I can't even think of a reason why a comment would cause a 10% speed reduction. Something has seriously gone very wrong there.
  - sonthonax 9y ago
    Agreed. What the absolute hell? This entirely contradicts how I understand programming languages work. Whitespace, tokens, formatting, should be irrelevant once it's all in an AST.
    - hdhzy 9y ago
      This is just a simple heuristic that's good enough for real code on the web. Usually whitespace and comments are stripped out during build step. I imagine this heuristic was implemented as something simple and working and that's that. Remember that they are not writing a monument of perfect software but something pragmatic that should work good in most cases.

Node 8.3.0 released

172 points by binarray2000 9y ago

k__ 9y ago

Nice. Any noticeable performance gains in everyday use?

__s 9y ago
They link https://medium.com/the-node-js-collection/get-ready-a-new-v8-is-coming-node-js-performance-is-changing-46a63d6da4de https://medium.com/the-node-js-collection/get-ready-a-new-v8... I'm mostly glad it'll come with an updated WebAssembly, hopefully fixing this bug: https://bugs.chromium.org/p/v8/issues/detail?id=6204 https://bugs.chromium.org/p/v8/issues/detail?id=6204 which blocks Luwa from working in node (handwritten wasm has a tendency to run into things emscripten would not.. I expect the same vice versa) Will also enjoy not having to use a TextEncoder/TextDecoder shim. Kind of weird that they went full out with Unicode there, last I recall browsers were moving towards only supporting utf8
- romanovcode 9y ago
  > write high performance JavaScript Does anyone with high performance requirements writes JS? Isn't that setting yourself up for failure on the first step?
  - jaegerpicker 9y ago
    Depends on your application and style of development. In my experience Node.js is almost always much faster than Ruby/Python and in some cases it's much faster than Java Spring type apps for certain types of network applications (mainly io bound web apps serving a lot of small requests, the event loop async nature of node really shines there). It's not C/C++ or pure Java or Go type of speed but for a lot of web application development? Node.js is great performant choice.
  - merpnderp 9y ago
    "Does anyone with high performance requirements writes [JS, Python, PHP, Ruby, Perl, Tcl, Shell, Scheme, Lua]? Isn't that setting yourself up for failure on the first step?" And yet there are a plethora of cases where all of those languages have been used with high performance requirements.
    - romanovcode 9y ago
      Yeah, that's my point. I'm not hating on JS or dynamic languages but to me it seems a stupid decision to go with that kind of language if you really need performance.
      - coldtea 9y ago
        That's assuming you ONLY need performance. How about you needing performance AND web compatibility?
  - Cthulhu_ 9y ago
    Not when JS is fast enough, and if you want standards-compliant web games (like webgl), it's your only option. There's a big number of startups that used Node for their back-end, if it becomes faster without them having to rewrite their codebase, that's a win too.
  - skibz 9y ago
    > Does anyone with high performance requirements writes JS? It's possible to call into C from Node. So there's nothing stopping you from implementing performance-critical parts of a system with native code, and then invoking it from JavaScript.
    - coldtea 9y ago
      Nothing except of it being messy and you ending up with two problems (to paraphrase JWZ).
  - coldtea 9y ago
    >Does anyone with high performance requirements writes JS? Isn't that setting yourself up for failure on the first step? You assume that "high performance" is the only requirement, so that it dictates everything. People also have other requirements like "it has to run on a browser/on the web" etc AND high performance. It's not like HPC people suddenly rush to use JS. But there are people targeting the web/node etc that DO want as high performance as they can get away with (e.g. web games).
  - SOLAR_FIELDS 9y ago
    Yes, there are use cases for high performance JS. We have JS that we use client side that we also use server side for Hadoop processing of data. So we didn't want to rewrite and maintain this large codebase in both Scala/Python and JS, so we ran Node on Hadoop. No, it really isn't setting yourself up for failure if you do it correctly. Node really is quite fast; for our use case it rivaled Java 8 runtime in MR CPU time, the only downside is it had double the memory footprint. With enough hardware, memory is not too much of an issue.
  - qaq 9y ago
    Walmart, PayPal etc. are doing fine running large scale apps on node.
    - romanovcode 9y ago
      Scalability is not performance.
  - westoque 9y ago
    It depends on the context of "high performance". For example, would a 400ms load time be considered "high performance"? I always say use the best tool for the job. And this usually means getting the requirements then laying out the solutions and picking the best solution out of the bunch.
  - akmittal 9y ago
    >Does anyone with high performance requirements writes JS? It bothers me that people still think JavaScript is slow. I think JavaScript(engines) is the only languages which is getting significant performance improvement on monthly basis since V8 was introduced. It is the abstraction people in JS/Frontend world people are used to, make it seem slow.
bricss 9y ago
Yaasss! New pipeline of Ignition and Turbofan provides huge performance increases. Read this article -> https://v8project.blogspot.com/2017/05/launching-ignition-and-turbofan.html https://v8project.blogspot.com/2017/05/launching-ignition-an...
- stonewhite 9y ago
  From the first chart in the link, I can't help but notice reddit is now slower with Turbofan + Ignition. It probably has something to do with a JS Dev who deeply understands how AutoCodegen works and driven the project accordingly.
  - bricss 9y ago
    I might say that some parts of code can perform differently depending on the style of source code.
calafrax 9y ago
I have run some very simple tests and performance is very close for real world complex apps, ~10% faster for an express hello world and ~10% slower for http stack only. Basically TF is at parity on average but slower for code like the node core that was highly optimized to the particularities of crankshaft. Hopefully npm 5.3.0 actually works since 5.0.0 was completely broken for me. v7.10.0 Test suite for real world app real 0m29.669s user 0m5.376s sys 0m0.356s v8.3.0 Test suite for real world app real 0m30.180s user 0m5.420s sys 0m0.220s v7.10.0 Express Hello World Requests per second: 6751.08 [#/sec] (mean) HTTP Hello World Requests per second: 13407.31 [#/sec] (mean) v8.3.0 Express Hello World Requests per second: 7734.33 [#/sec] (mean) HTTP Hello World Requests per second: 12601.42 [#/sec] (mean)

xori 9y ago

I wonder if this will lead to Electron using less RAM... nah.

v0lta 9y ago
It's the Chromium part of Electron that uses that much RAM.
- xori 9y ago
  Yea? But only because the old V8 had Crankshaft running in parallel. New version has this disabled IIRC.

bdefore 9y ago

Shame about npm5 being significantly broken, taking the wind of the node 8 sails. https://github.com/npm/npm/issues/16991 https://github.com/npm/npm/issues/16991

gcp 9y ago
How does npm5 compare to yarn? I didn't notice anything, but I'm using yarn everywhere, so...
- 0xptr 9y ago
  Speed wise npm@5 caught up a lot of ground. Iirc it was the same a while ago. However, I always felt like the release was a bit rushed. I sticked to Yarn too tho.
  - X-Istence 9y ago
    This is so completely and utterly wrong, unfortunately... Yarn takes 12 seconds to install all of our node_modules, npm@5 (latest) takes over 12 minutes. This made it completely and utterly untenable for our CI system, so we switched to yarn and shaved 12 minutes off our CI builds. It's been fantastic.
    - orf 9y ago
      That's got to be down to caching. What's the difference if the yarn cache is cleared?
      - X-Istence 9y ago
        25 seconds when the yarn cache is cleared... downloading is not the slow part here. Old results from about a month ago: https://twitter.com/bertjwregeer/status/887450964420055043 https://twitter.com/bertjwregeer/status/887450964420055043 npm 5.3.0: added 1991 packages in 538.289s yarn v0.27.5: Done in 58.42s.

jnbiche 9y ago

Still disappointed that Node has backed out of optimized tailcalls (edit: should have written proper tail calls here, since that's what the past 3 now specs have called for, ES5, ES6, and ES2017). I think it's the only part they haven't implemented. I think a lot of the pushback I'm seeing against TCO comes from traditional programmers who don't like functional programming and who think that recursion shouldn't play any role in production software. I get that there are also some who have legitimate implementation concerns, but the reflexive pushback TCO gets from a lot of the V8 maintainers compared to any other new ES6 feature seems telling to me (correct me if I'm wrong here). What they don't understand is that JavaScript programmers are rapidly moving toward functional programming. Already, there's a heavy functional influence on the React community, probably the dominant frontend framework/library at the moment. Clojurescript and Elm have had an outsize influence on the JavaScript community, and I see more and more programmers using functional paradigms in their everyday code (particularly maps, filters, and reductions). I know we'd see much more recursion if it were technically feasible. Edit: Absolutely right, my critics. I brain farted on this one. It's not Node, it's V8. I did refer to this in the second paragraph, but stupidly blamed Node for it in the first paragraph. Edit 2: As I said, I shouldn't have singled out Node, particularly since it's V8 that's making this call. But my criticism was more directed toward most of the JavaScript implementers who seemed to have single-handedly decided that the es6 spec was all cool except for the one part they don't like. And I could accept the criticism that implicit tailcalls are problematic, except they seem opposed to labeled tailcalls as well. I think there are lots of implementers who simply don't believe that recursion has a place in "real" software. I've not heard these exact words from an implementers before, but I've known quite a few senior developers of my generation (40s) who have said this exact thing to me (they also can't seem to get the difference between structural and generative recursion).

koolba 9y ago
Does V8 handle them? If not how would we expect Node to do so?
- jnbiche 9y ago
  You're correct, I updated my post accordingly.

Phlow 9y ago

Still can't get a debugger; statement to break... https://github.com/nodejs/node/issues/7593 https://github.com/nodejs/node/issues/7593

erikpukinskis 9y ago
It's amazing to me how blazé the Node community is about breaking the debugger. In other language communities that would be considered sacrilege, but in Node the response is often "meh... I just console.log everything". Transpiling, source maps, so many hacks that barely work.

sparrish 9y ago

I've been waiting for this DNS behavior change for years. Great release!

nessup 9y ago

From the Medium post about speed improvements in this version: > The size of a function, including it’s signature, the white space and even comments can affect whether the function can be inlined by V8 or not. Yes: adding a comment to your function may cause a performance hit somewhere in the range of a 10% speed reduction. Uhh... byeee

dbbk 9y ago
I can't even think of a reason why a comment would cause a 10% speed reduction. Something has seriously gone very wrong there.
- sonthonax 9y ago
  Agreed. What the absolute hell? This entirely contradicts how I understand programming languages work. Whitespace, tokens, formatting, should be irrelevant once it's all in an AST.
  - hdhzy 9y ago
    This is just a simple heuristic that's good enough for real code on the web. Usually whitespace and comments are stripped out during build step. I imagine this heuristic was implemented as something simple and working and that's that. Remember that they are not writing a monument of perfect software but something pragmatic that should work good in most cases.