Coordinate pairs in JavaScript

Any application that works with 2D spaces, grids or tile maps needs a way of representing individual points as coordinate pairs. These will be extremely common short-lived objects in a wide variety of scenarios so I was curious to see the impacts of different representations across different browsers.

Overview

There’s a huge variety of things to look at here. To scratch the surface, I constructed a series of jsPerf benchmarks using the common pattern of enumerating neighbouring grid cells for a given x,y point as an adjacency list (without actually using an adjacency list data structure).

This approach is widely used to generate maps using cellular automata and run pathfinding algorithms, so the tests roughly approximate the kinds of real workloads one might see in a game or simulation.

The tests are initialised with a set of identical map grids containing a random distribution of cells marked as either ‘ocean’ or ‘land’ tiles. Each test iterates through every cell in the map and flips the marked tile if the majority of surrounding cells are a different kind of tile.

Representations

Array with two indices

[x, y]

Object literal with x,y properties

{
  x: x,
  y: y
}

Prototype constructor with x,y properties

function Point(x, y) {
  this.x = x
  this.y = y
}

ES6 class with getters

class Position {
  constructor(x, y) {
    this._x = x
    this._y = y
  }

  get x() {
    return this._x
  }

  get y() {
    return this._y
  }
}

Disclaimer

These benchmarks aren’t authoritative or definitive. At best, they give a rough overview of the characteristics of allocating memory in several different ways in the specific context of these tests.

It’s possible that the way I’ve implemented the loops could be confounding the measurements and there are a couple of changes I can make that will have a major impact on garbage collection.

Browser JavaScript engines change often (usually getting faster and faster) so this is really just a snapshot in time. YMMV.

Measurements

All results measured in ops/sec (higher is better).

Tested on: Mac OS X 10.12.5, 2.2 GHz Intel Core i7, 16 GB 1600 MHz DDR3.

Array with two indices

Object literal with x,y properties

Prototype constructor with x,y properties

ES6 class with getters

ES5 Object.assign

Chrome

Firefox

Safari

Summary

There’s probably nothing here that is remarkable or unexpected.

Chrome wins at smaller collection sizes. Safari wins at larger collection sizes.

Between 200 and 500 cells, garbage collection seems to wash out any major differences between implementations.

Storing points in two element arrays is slightly slower than using object properties. Firefox arrays are closer to object properties in performance than in the other browsers.

Safari seems to exhibit a much greater standard deviation at smaller grid sizes.

In general, getter method wrappers are slower than direct property access.

Don’t use Object.assign in hot code paths. I included this out of curiosity and unsurprisingly, it was much, much slower. It’s also not a great fit for the problem of creating thousands of short-lived objects (though this isn’t a reason to avoid it in general—it’s a really useful feature!).

Resources

• Fast properties in V8 explains how properties are handled internally in the V8 engine, which provides useful context for understanding these results.