Concurrent JavaScript — Part II: Input/Output

Abdullah Ali
3 min readApr 26, 2016

--

So, in my previous article, I introduced you to Nexus.js, Node’s multithreaded — and arguably mad — cousin:

Today, I’ll introduce you to more aspects of the runtime that I’ve committed to the git repository this morning.

Meet the pipe command:

The pipe command is simple, it channels an input stream into an output stream, applying all filters in-between, and returning a promise that resolves on I/O completion.

What you’ve witnessed above is 100 megabytes of text converted from UTF8 to UTF16LE in 0.569 seconds.

Impressive, right? So, let’s leverage multithreading:

Now, this is interesting… You see, we’ve just converted 400MB of text from UTF8 to UTF16LE in 1.8 seconds!

This doesn’t make sense, it should take four times the duration to convert the data. It should have been 2.276 seconds, precisely. There is a duration of 0.476 second missing.

So, we’ve established that there’s ~0.5 second difference. So what? That’s nothing, right?

Wrong.

That’s the difference between a 0.5 second Time-To-First-Byte and a 1 second TTFB on a web server. That’s 69.5 less hours of computing for one million requests to the same web server.

Not very important to most people, and utterly crucial to some.

Now let’s try the same benchmark with Node:

Node finishes the same test in 6.356 seconds, compared to Nexus’ 1.8 seconds!

Note that I couldn’t use Node’s .pipe because it can’t be used in this scenario, or at least I couldn’t figure out how. I would love to see you implement something faster that I can properly benchmark.

See you again soon!

The source code for the project is available at GitHub. Feel free to check it out. Also feel free to follow me on Twitter for real-time updates on the project!

Update:

It looks like there is a more efficient method to do this with Node, I wasn’t accurate in the sense that it can be done using streams in Node:

Still, it takes 3.8 seconds, compared to 1.8 seconds in Nexus. Note that file flushing in both cases is to blame.

--

--