My understanding of the technology is that it is compiled on the fly into assembly. On the speed spectrum it is slower than Java but faster than Ruby and Python. On the client side an interpreter makes sense but on the server side my first thought is that compilation prior to running, or at least having the option to do so, is an optimal architecture. If the JavaScript was pre compiled in this way would it run faster than Java? Or is it something to do with weakly typed languages which means that JavaScript will always be slower than Java?
Some of Node.js is C++ and is pre-compiled. My understanding though is that there was an effort to keep as much of it in Javascript as possible, but where performance was poor then C++ was used.
Node.js would not be possible without the V8 JavaScript Engine, which is what compiles the javascript. This engine is well-known for being extremely fast. It was built for the Chrome browser, but the performance pays off in Node.js too.
Regarding performance of Node.js, as a web server it is at least on a par with the other leading web servers like Apache+PHP. So performance is not an issue in the common use case. That said, there are faster technologies. Erlang based servers are known for being faster under concurrent loads (interestingly, Erlang is also a dynamically typed language).
For pure number crunching cpu/gpu intensive tasks, Node.js is not a good choice, unless you temper it with Fabric Engine, in which case it can be on a par with C++.
There are a couple of projects that are currently exploring speed issues with JavaScript:
Dart - http://www.dartlang.org/support/faq.html. (Its not just about speed but that is part of it).
Node Native - https://github.com/d5/node.native/
Related
In Node, does it make sense to port some logic to wasm for json manipulation operations in order for the algorithm to be quicker?
tl;dr Don't use WASM for JSON manipulation.
Setting up the WASM tooling is no small thing, and will likely require more ongoing troubleshooting and maintenance than lighter-weight solutions.
Wasm generally comes into its own when you need to do truly compute-intensive stuff like customized signal (image/video/audio) processing for your browser users or natively inside server-size Javascript environments.
If your purpose in doing this is avoiding overhead in JSON processing, you might consider looking for fast JSON packages on npm. fast-json-stable-stringify is an example.
You should also keep this in mind: V8 -- the open-source Javascript engine in nodejs, deno, and chromium -- is under active development by a large and highly competent team at Google. That engine includes the JSON. functions. Performance improvements show up in every release, and they're highly motivated to keep making things faster. JSON handling is one of those areas. If you roll your own, your code won't get any faster with the next release of V8/nodejs. If you use the stuff in V8, it might.
Take a look at this dev summit presentation, for example. Maybe you can outsmart the V8 team. If so you should join them.
So, if you want to learn WASM, do something that will add interesting new capabilities to your personal toolbox.
Unlikely. The V8 engine has a pretty good JIT compiler. If it is a hot path and properly written, it will become machine code anyway.
Google's open sourced V8 engine is mature, performant JIT compiler.
Implemented primarily in C++, acting as JS centric execution runtime.
It has an isolation implementation (V8: Isolates), providing isolation granularity within a single process.
Leading to two part question.
(Generic)
Can this capability be broadly used for isolation across server-side web application engines (e.g. nginx, apache) and programming languages?
(And more specific ->)
What I've grasped of V8 - is that it's designed for JS scripting lang (even though, it compiles directly to machine code).
Wanting to use a programming language for source code - say Haskell, C++/C - then tends to still have JS interface in between.
Would there be a much direct way to generate machine code, while still using V8: Isolates?
V8 is a JavaScript (and WebAssembly, in recent versions) engine and as such cannot be used to compile or execute any other languages.
If you have C++ code, you'll need to use a C++ compiler to generate executable machine code for it. Haskell code needs a Haskell compiler.
Depending on your requirements, WebAssembly might be interesting to you: it is a portable compilation target for languages like C++ that is more suitable for this purpose than JavaScript.
This should answer both your "more specific" and the "generic" question.
Note that there isn't really any magic in V8's Isolates that one might want to use for other purposes; the term mostly describes the ability to have several separate instances of V8 in the same process. That's rather easy to pull off if you start your own project from scratch (no matter what its purpose is), you just have to maintain a bit of coding discipline; for an existing codebase it requires refactoring of all global state (static variables etc).
Also, note that the world has learned this year that from a security point of view, there really is no such thing as in-process isolation. If you have strong security requirements, then at the very least you'll have to run separate processes for different security domains. (To be clear, V8's Isolates do not provide protection from side-channel attacks.)
I have got a use case in which I have to do image search in node JS application. I have image hash stored in database, so I need to calculate hash in nodeJS application. I may have more computer vision use cases in future. I came across nodejs-opencv module, but none of the blogs talk about its performance. As nodeJS is not supposed to be used for CPU intensive tasks and computer vision algorithms may need heavy processing I am not sure how well it will scale. Has someone used it in production and provide some details ?
Which nodejs OpenCV library are you talking about? If you pick one that provides javascript bindings from a native node module then you will have the same performance as with C++. I am currently working on an OpenCV 3.x native node addon to use OpenCV with javascript and can tell you that there is really no difference in performance. However there are also implementations in pure javascript without the need of setting up the OpenCV c++ library on your server or local system but most of the CV tasks will be significantly slower if implemented in javascript as you already guessed.
The most performant way to use computer vision in NodeJS project is move the calculations into C++ codespace (native addon) and apply Workers for multithreading
There are more and more references in the Node.js community to "CrankShaftScript" (and "CrankShaftJS") on Twitter, GitHub, and Facebook group discussions. I thought Node.js was written in C++ and JavaScript, so what is CrankShaftScript referring to in performance regression bugs like this one:
https://github.com/nodejs/CTC/issues/146#issue-237435588
CrankShaftScript is the name given by the community to JS idioms (such as certain types of loops) that run faster(est?) on V8's CrankShaft engine.
CrankShaft is being replaced by an engine named TurboFan. Lots of JS code written by devs over the years has been written specifically to run fast on CrankShaft (e.g. written in "CrankShaftScript") using the known idioms that run fast on CrankShaft - this is no longer necessarily the case because the V8 engine is now different and the code that ran fastest on CrankShaft is not necessarily guaranteed to run fastest on TurboFan.
In case my answer is too verbose, here's a great comment on the NodeJS Benchmarks thread that may detail it better:
...I noticed that some parts of Node core are sort-of written in
CrankshaftScript, i.e. carefully tuned towards stuff that works
extremely well in Crankshaft.
CrankShaftScript is a community-adopted term used for non-idiomatic and/or non-standard compliant JavaScript that will only execute and/or perform well in the specific versions of the v8 JavaScript runtime that employ the CrankShaft JIT compiler. Specific examples include: loops written in a difficult-to-maintain fashion to work around JIT optimization deficiencies in v8, and use of v8-specific built-in functions/globals.
This term was originally coined to describe some root performance issues in node-chakracore and spidernode, which are Node.js distributions that employ the ChakraCore and SpiderMonkey runtimes instead of v8.
It is now being used as shorthand to explain why the Node.js 8.1 release series, which updated to a newer version of v8, has several performance regressions in micro- and macro-benchmarks due to v8's CrankShaft JIT being superseded by TurboFan (sometimes referred to as "TF"). As in these issues:
https://github.com/nodejs/node/issues/11851#issuecomment-287253082
https://github.com/nodejs/CTC/issues/146#issuecomment-310229393
https://twitter.com/matteocollina/status/870580613266501632
For these reasons, the Node.js community is actively working on excising instances of CrankShaftScript in Node.js core code, as well as in common npm packages. This should help alternative Node.js distributions like node-chakracore perform better and ease the risk of future upgrades to the JavaScript runtime in Node.js.
CrankShaft is the compilation infrastructure for V8, Node.js' Javascript runtime (details).
It's now being replaced by TurboFan.
What would be the advantages, if any, of using a node.js addon written in C/C++ compared to calling a binary with arguments through child_process?
More specifically, I have a small program, which accepts possibly up to a few hundred arguments and returns a boolean.
There is a huge difference.
C++ Addon is native code which is running as part of main application (on the same level as JS does). But if you use child_process, node will start new process and there is a huge overhead (spawning processes is much more complicated than running native code in one thread).
If you are deciding, which approach to use, it heavily depends on your situation. If you are familiar with C++ and you want to handle thousands of requests, you probably should consider writing an addon. But if you are writing a small app for personal use and your additional program is already functional as stand-alone app, I would use child_process and it can also provide great results with less effort.