Node: synchronous code runs faster than asynchronous code

Writing Node code? What for?

If you’re coding your own web server, you’ve probably read that you should never use fs.readFileSync(): instead, you should use fs.readFile() and endure callback spaghetti.

I’ll add a corollary: if you aren’t coding your own web server, use fs.readFileSync().

Prefer synchronous code, when it’s an option. It’s faster and simpler. For instance, reading lots of small files:

In this example, synchronous code is 6–7 times faster than asychronous code.

Async pundits may protest. “Why not read the files in parallel?”, they’ll ask. (The answer: that causes EMFILE: too many open files — and it takes longer to generate that error message than it takes synchronous code to read all the files. A workaround would take lots more code, and it would still be slow.) Perhaps they’ll say, “But that isn’t real-world code!” … to which I’ll reply: I’ve observed dramatic real-world speedups and simplifications by switching to synchronous code.

When to use synchronous code

You have to make a decision every time you write a line of code. Sorry.

The basic question is: “should code run in the background while I’m reading this file?” If yes, use async. Otherwise, use sync.

It’s often a judgement call. Here are the basics:

Use sync for in-memory operations — async is a complete waste when you aren’t making blocking calls.

Use async when designing a library that makes blocking calls — unless you know all users want to use your library synchronously. You can add synchronous code as a feature once you’ve finished the async version.

Use async when a library you depend on forces async — because you have no choice. But consider contributing a synchronous version of the library.

Use sync for non-parallel tasks — such as computations or system-administration scripts.

In sum: async is often a mistake. Code appropriately.

Next up: streams.