I have started reading a lot about Node JS lately and one thing I am not able to clearly understand from differentiation perspective is what is the real difference between how I/O is handled by Asynchronous Vs Synchronous call.

As I understand, in a multi threaded synchronous environment , if I/O is started , the running thread is preempted and moves back to a waiting state.So essentially this is same as what happens with NodeJS asynchronous I/O call. In Node JS, when I/O is called, the I/O operation is moved out of current running thread and sent to event De-multiplexer for pletion and notification. As soon as I/O is plete the callback method is pushed to event Queue for further processing.

So , the only difference I see is that in Node JS we are saving memory (due to multiple call stacks owned by each thread) and CPU ( saved because of no context switching). If I just consider that I have enough memory to buy , does saving of CPU due to context switching alone is making the huge performance difference?

If my above understanding is not correct, how does I/O handling is any different between a java thread Vs Node JS w.r.t to keeping the CPU busy and not wasting CPU cycles.Are we saving only context switching CPU cycles with Node JS or there is more to that?

Based on the responses , I would like to add another scenario:

Request A , Request B es to J2ee server at the same time. Each request takes 10 ms to plete in this multi threaded environment.Out of 10 ms , 5 ms is spent in executing the code logic to pute some logic and 5 ms is spent in I/O for pulling a large dataset from a DBMS.The call to DBMS is the last line of the code after which the response should be sent to the client.

If same application converted to a node JS application, this is what might happen

1. Request A es, 5 ms is used for processing the request.

2. DBMS call is hit from the code but it's non blocking.So a callback method is pushed to event Queue.

3. After 5 ms, Request B is served and again request B is pushed to event Queue for I/O pletion.Request B takes 5 ms for processing.
4. Event Loop runs, pickups callback handler for request A, which then sends the response to client.So the response is sent after 10 ms because Req A and Req B both took 5 ms for synchronous code block processing.

Now where is the time saved in such a scenario?Apart from context switching and creating 2 threads. Req A & Req B both took 10 ms anyway with Node JS. ?

I have started reading a lot about Node JS lately and one thing I am not able to clearly understand from differentiation perspective is what is the real difference between how I/O is handled by Asynchronous Vs Synchronous call.

As I understand, in a multi threaded synchronous environment , if I/O is started , the running thread is preempted and moves back to a waiting state.So essentially this is same as what happens with NodeJS asynchronous I/O call. In Node JS, when I/O is called, the I/O operation is moved out of current running thread and sent to event De-multiplexer for pletion and notification. As soon as I/O is plete the callback method is pushed to event Queue for further processing.

So , the only difference I see is that in Node JS we are saving memory (due to multiple call stacks owned by each thread) and CPU ( saved because of no context switching). If I just consider that I have enough memory to buy , does saving of CPU due to context switching alone is making the huge performance difference?

If my above understanding is not correct, how does I/O handling is any different between a java thread Vs Node JS w.r.t to keeping the CPU busy and not wasting CPU cycles.Are we saving only context switching CPU cycles with Node JS or there is more to that?

Based on the responses , I would like to add another scenario:

Request A , Request B es to J2ee server at the same time. Each request takes 10 ms to plete in this multi threaded environment.Out of 10 ms , 5 ms is spent in executing the code logic to pute some logic and 5 ms is spent in I/O for pulling a large dataset from a DBMS.The call to DBMS is the last line of the code after which the response should be sent to the client.

If same application converted to a node JS application, this is what might happen

1. Request A es, 5 ms is used for processing the request.

2. DBMS call is hit from the code but it's non blocking.So a callback method is pushed to event Queue.

3. After 5 ms, Request B is served and again request B is pushed to event Queue for I/O pletion.Request B takes 5 ms for processing.
4. Event Loop runs, pickups callback handler for request A, which then sends the response to client.So the response is sent after 10 ms because Req A and Req B both took 5 ms for synchronous code block processing.

Now where is the time saved in such a scenario?Apart from context switching and creating 2 threads. Req A & Req B both took 10 ms anyway with Node JS. ?

• javascript
• node.js
• multithreading

Share Improve this question Follow edited Mar 16, 2016 at 17:53 learnerFromHell asked Mar 16, 2016 at 5:08 learnerFromHelllearnerFromHell 19311 silver badge99 bronze badges 5

• 1 Your example is a single series of events that depends on the pletion of the last before the next. Node is not going to speed that up, in fact its theoretically impossible to do that because you require the last value for the next task. What node is good at is say you wanted to handle many of these events you can do that concurrently, rather than only being able to handle one at a time. Your example doesn't make much sense in an aspect of concurrency or parallelism. – tsturzl Commented Mar 16, 2016 at 6:05
• No threads were ever created, no contexts were switched. I think this answer should be closed because I don't think it can be answered. – tsturzl Commented Mar 16, 2016 at 6:06
• Time is saved because instead of blocking execution it can move on to handle other things, but you can't move on in the same serial task without the value from the previous task. Its a better approach to threading as I explained in my ments on the answer below. Context switching has memory and CPU overhead. It's heavy and not well suited for concurrent IO. An eventful or streaming style of concurrency like nodejs provides is lightweight and perfectly suited to IO, same goes for something like coroutines. These require less allocations, context switching, and memory. – tsturzl Commented Mar 16, 2016 at 6:10
• Essentially sacrificing low level control for performance and reduced overhead. Context switching is heavy, allocating that memory is very heavy(usually why you have a threadpool), and for IO those low level controls are not needed. Threads are essentially schedule similarly to processes, they switch context and that requires many CPU cycles on its own. Threads are expensive, even in a thread pool. You save more than memory, you save a lot of useless work switching contexts which is no light task. – tsturzl Commented Mar 16, 2016 at 6:18
• learn-gevent-socketio.readthedocs/en/latest/… – tsturzl Commented Mar 16, 2016 at 6:20

Add a ment  | 

1 Answer 1

Sorted by: Reset to default 5

As I understand, in a multi threaded synchronous environment , if I/O is started , the running thread is preempted and moves back to a waiting state.So essentially this is same as what happens with NodeJS asynchronous I/O call.

Nope, in NodeJS an asynchronous I/O call is a non-blocking I/O. Which means that once the thread has made an I/O call it doesn't wait for the I/O to plete and move on to the next statement/task to execute.

Once the I/O pletes it picks up the next task from event-loop-queue and eventually executes callback handler which was given to it while making the I/O call.

If I just consider that I have enough memory to buy , does saving of CPU due to context switching alone is making the huge performance difference?

Apart from this, saving is also ing from these two things

• Not-Having-To-Wait for the I/O to plete
• Not-Having-To-Make-Threads since threads are limited, so the system's capacity is not limited by how many threads it can make.

Apart from context switching and creating 2 threads. Req A & Req B both took 10 ms anyway with Node JS. ?

You are discounting one thing here - Thread is getting two request one after the other after a specific interval. So if one thread is going to take 10 seconds, then it will take a new thread to execute the second request. Extapolate this to thousands of requests and your OS having to make thousands of threads to deal with so many concurrent users. Refer to this analogy.