You Don't Know JS: Async & Performance

Chapter 6. Benchmarking & Tuning

As the first four chapters of this book were all about performance as a coding pattern (asynchrony and concurrency), and Chapter 5 was about performance at the macro program architecture level, this chapter goes after the topic of performance at the micro level, focusing on single expressions/statements.

One of the most common areas of curiosity—indeed, some developers can get quite obsessed about it—is in analyzing and testing various options for how to write a line or chunk of code, and determining which one is faster.

We’re going to look at some of these issues, but it’s important to understand from the outset that this chapter is not about feeding the obsession of micro-performance tuning, like whether some given JS engine can run ++a faster than a++. The more important goal of this chapter is to figure out what kinds of JS performance matter and which ones don’t, and how to tell the difference.

But even before we get there, we need to explore how to most accurately and reliably test JS performance, because there’s tons of misconceptions and myths that have flooded our collective cult knowledge base. We’ve got to sift through all that junk to find some clarity.

Benchmarking

OK, time to start dispelling some misconceptions. I’d wager the vast majority of JS developers, if asked to benchmark the speed (execution time) of a certain operation, would initially go about it something like this:

var start = (new Date()).getTime(); // or `Date.now()` ...