How is Node.js inherently faster when it still relies on Threads internally?

Viewed 41577

I just watched the following video: Introduction to Node.js and still don't understand how you get the speed benefits.

Mainly, at one point Ryan Dahl (Node.js' creator) says that Node.js is event-loop based instead of thread-based. Threads are expensive and should only be left to the experts of concurrent programming to be utilized.

Later, he then shows the architecture stack of Node.js which has an underlying C implementation which has its own Thread pool internally. So obviously Node.js developers would never kick off their own threads or use the thread pool directly...they use async call-backs. That much I understand.

What I don't understand is the point that Node.js still is using threads...it's just hiding the implementation so how is this faster if 50 people request 50 files (not currently in memory) well then aren't 50 threads required?

The only difference being that since it's managed internally the Node.js developer doesn't have to code the threaded details but underneath it's still using the threads to process the IO (blocking) file requests.

So aren't you really just taking one problem (threading) and hiding it while that problem still exists: mainly multiple threads, context switching, dead-locks...etc?

There must be some detail I still do not understand here.

7 Answers

Node.JS is not faster (doesnot means its slower either), but highly efficient in handling a single thread, as compared to a blocking multi-threaded system handling its single thread!

I have made diagrams to explain this statement with analogies.

enter image description here enter image description here

Now offcourse one can build a non blockig system on top of a blocking multi-threaded system (thats what Node.js is under the hood), but its very complex. And you have to do it ever where you need non blocking code.

Javascript ecosystem (like nodejs) provide this out of the box as its syntax. The JS language sytanx provide all this feature where ever needed. Morever as its part of its syntax, the reader of the code immeditetly knows that where code is blocking and where its non-blocking.


The blocking part of multithreaded-blocking system makes it less efficient. The thread which is blocked cannot be used for anything else, while its waiting for response.

While a non-blocking single threaded system makes best use of its single thread system.

Related