What is the difference between CPU intensive and I/O intensive?

Question

What is the difference between CPU intensive and I/O intensive?

Why node js is not CPU intensive?

Answer 1

CPU intensive is code that uses a lot of CPU cycles. For example, encryption/decryption or video transcoding would be heavy loaders of the CPU.

I/O intensive is code that uses a lot of I/O (networking or disk, typically) which are operations that are mostly offloaded to the operating system and involve interfacing with external hardware more than they do using lots of CPU.

It is generally said that nodejs is particularly good at I/O intensive code because of it's non-blocking, I/O architecture. It can very efficiently have lots of I/O operations in flight at the same time (more so than architectures that would typically use a separate thread for every I/O operation).

In general, nodejs runs your Javascript in a single thread and only thus uses a single core for that so it's not great at doing a bunch of things that take a lot of CPU because it doesn't generally engage more than one CPU core so CPU-intensive operations don't run in parallel, but get serialized one after another.

In addition, because of the single threaded nature of running your Javascript and the event driven architecture, when the interpreter is running a CPU-intensive operation, it can't be doing anything else. Other things (like new networking requests arriving at your server) have to wait until the CPU intensive code is done. There is no timeslicing among multiple threads of your Javascript to balance the scheduling.

So, this very efficient non-blocking, I/O architecture combined with the single threaded running of your Javascript creates this notion that nodejs is great at lots of I/O and not great at operations that require lots of CPU.

Now, there are ways to work-around the operations that require lots of CPU. The newer versions of nodejs have Worker Threads so you can now fire up as many threads as are useful and enhance the overall performance of running your CPU intensive code by moving the CPU intensive code out of the main thread so it remains free to run the event loop. And, you can use the Worker Threads to engage more CPU cores in doing your CPU intensive work.

For example, if you had an app that did a bunch of heavy encryption, you might fire up a small pool of worker threads and then create a queue of encryption work. When the main JS thread wanted to do some encryption, it would submit a job to the encryption queue and one of the worker threads in the pool would crunch on the encryption job. It would have a non-blocking, asynchronous interface to it so the main thread would not be blocked and would be free to do other things (like serve other requests) and when the worker thread was done, it would send a message to the main thread which would get notified and could then access the encryption result without ever blocking the main JS thread.

You can also use the built-in clustering module to engage multiple CPUs in processing incoming work (whether CPU intensive or networking intensive).