Optimizing Array Analytics In JavaScript: Part One — Iterating Functions

It today’s data rich world there are a lot of programs that manipulate fairly large arrays in JavaScript. This is the first in a three part series about how to optimize those programs.

Although the iteration functionsforEach, every, some, mapand reduce may be your friends for writing concise safe code, they may not be your friends when you need performance. We address these functions along with some interesting differences in performance between browsers and Node.js in Part One.

Look-ups are often critical and you might be interested in insort, a means of inserting into an array so that it is always in sorted order for binary searching. And, when it comes to combining arrays, the default intersection function in your favorite library may not be doing you any favors. Beware the Cartesian cross-product from both a memory and performance perspective unless you know how to be pro-actively lazy. (An odd statement … pro-actively lazy … more on that in Part Two).

Computing statistics such as max, min, avg, can be expensive. Optimization opportunities identified for iteration can be applied and values should be cached until they need to be re-computed. These topics will be addressed in Part Three.

All benchmarks in these article are produced using the library benchtest. Benchtest wraps the superb benchmark.js library to add some standardized report and unit test capability.

The benchmarks are run on a Windows 10 64bit 2.54gz machine with 8GB RAM and a non-SSD hard drive. The tests are isomorphic and are run using Node v9.4.0, Chrome v64, Firefox v58, and Edge v41.

The default array used for testing is 1000 elements long with the values corresponding to the index in the array. All the iteration routines and functions call the same test function:

function(value) { return value===this.array.length/2; }

Some of the benchmark results are shocking, i.e. browser code running faster than Node.js and hand-written code running faster than built-in code. In order to confirm results, three things were done:

1. Some of the tests were re-written directly in benchmark.js to rule out issues with benchtest.
2. Unit tests were added to the benchtest suites to ensure the hand-written code was returning the same results as internal code.