HN Explorer

39 comments

[ 3.3 ms ] story [ 93.8 ms ] thread
rf15
I'm always impressed by some of the optimisations they find: 0aa403b649 improves readDouble/readFloat in buffers by 200-800% simply by...moving the code to plain javascript binary operations instead of the C++ runtime.
coolspot
My understanding is that transitions between C++ runtime and JS context are relatively expensive.
Something1234
What generates that improvement percent confidences that was included in that commit?
dingdingdang
Yeah, could be that you see 200% improvement on first call and then proceed to suffer 2000% slowdown unless this is benchmarked properly.
__s
Given the context it's likely the other way around

Nobody really cares if your 1 call is 20x slower though. Much better to make it 2x faster when there's 100 calls

Something1234
I was talkiing about the tooling that generated the output, but this is a valid point too. Still want to know what the tooling is.
rf15
They probably just timed execution with a few thousand samples and compared results. Nothing too fancy either way, I think.
appdrag
AWS Lambda is still only supporting Node.js 6.10, they need to move faster...
koolba
You can run any Linux binary you'd like if you bundle it yourself. Just use the built-in node runtime as a shim to run your process. It doesn't have to be newer node version Node either ... you can use it to run any standalone executable.
appdrag
So this mean having a multi megabytes zip for the function instead of 1kb with a native runtime, this also affect cold start loading time of the lambda function ...
Shoothe
Does this really affect the cold start? Even if you use the native runtime it still is running in a separate container and you need to start the node process anyway. (Honest question, didn't measure it).

The size would definitely be affected.

k__
True.

I read that someone builds a Reason/OCaml library with Node.js like API that compiles to native binaries, but uses OCaml standard libary functions in the background, which could probably get much smaller than Node.js.

Osiris
Azure App Services / Functions support up to 8.9.3. They move pretty quick to add new node releases.
nfriedly
Bluemix's OpenWhisk has been much better about keeping up with Node.js releases FWIW. (I used to work for IBM.)
bdcravens
For the longest time they were still on 0.10. (deprecated 11/16, fully removed 4/17)
cridenour
It's a shame that updating node via homebrew is such a pain that I probably will skip this version.

Maybe it's just me, but every upgrade corrupts the global node_modules.

minxomat
Shouldn't nvm (node version manager) work? I rarely install node via any package manger, nvm provides some nice management features.
apazzolini
https://github.com/tj/n is also a good version manager for node.
coding123
I tried nvm and it didn't even install correctly. I tried n just now and it works beautifully! thanks for the ref. Nice that it is from tj.
beart
I'm not sure how homebrew works but most of the node version managers will keep independent global installation folders for a version of node.

You could try using something like nvm which has a command to migrate your old global modules.

nvm install node --reinstall-packages-from=node

code-e
Are you talking about native modules that need to be rebuilt when the V8 version used by node is also upgraded?
zumu
Why not use a version manager like n or nvm?
vijaybritto
I hope they release a cross platform installation script or binary that can manage multiple versions like nvm(doesn't work on windows). Hmm, since I'm learning Go now this might be a good exercise.
altano
nvm works on Windows for me?
dvlsg
Same here. It's a separate application from the non windows versions though. I seem to remember having to search explicitly for the windows version.
atomicfiredoll
You may be running nvm-windows, which is a separate project run by different developers.
steveklabnik
I use 'nodist', which happens to be written in Go, if you need some inspiration!
johnsonjo
I'm still awaiting async iterables [1] in Node.js. It's not part of ECMAScript yet, but I'm still excited for it. Chrome 63 and v8 6.3 enables async iterables, but this Node.js version (v9.4) uses v8 6.2 so no async iterables yet. Does anyone know whether a version of Node sticks with the same version of v8 throughout? So, is there any chance that a node version 9 will have v8 greater than 6.2?

[1]: https://github.com/tc39/proposal-async-iteration

WorldMaker
I believe that Node has been treating v8 upgrades as semver major breaking changes as it changes the ABI for native extensions, even though there are enough mitigating tools these days that most native extensions don't break on v8 upgrades.