Javascript array performance oddities


Heads up!

The blog has moved!
If you are interested in reading new posts, the new URL to bookmark is


I’ve recently attended a talk by a Google engineer part of the Google V8 team about writing efficient Javascript code with an eye on performance, obviously with a focus on V8, and I’ve started to read a lot on the topic.
What everyone seems to agree on is that there still is a widespread gap of performances between the different Javascript engines and also sometimes there are odd behaviour that will puzzle you, like the one I’m going to show below.
During the talk I was really impressed by huge performances gap between different approaches to array manipulation, most of the times due to differences in code that looked so trivial!
Before diving in, let’s have a super quick introduction to javascript arrays.

Small overview about Javascript arrays

(Extract from
Arrays are one of JavaScript’s core data structures.
Arrays are a special case of objects and they inherit from Object.prototype, which also explains why typeof([]) == “object”.
The keys of the object are positive integers and in addition the length property is always updated to contain the largest index + 1.

Arrays are very useful and used in contexts like games or mathematical simulations for example, where we may need to store and manipulate a lot of objects and we need to do it in a very short amount of time.

State of the art

The general consensus about V8 (and more generally about Javascript engines) has a few useful tips to speed up array manipualtion

  1. If you want to use an array data structure, then treat it as an array: do not mix the types of the data stored. For example in V8 when we first populate the array with data, the JIT creats a HiddenClass object that tracks element types, and if at a certain point we change the types by for example storing a string instead of a number, V8 will have to forget it all and restart, therefore dropping performances.
  2. pre-allocate (pre-allocate means specifying the array length) “small” arrays  in hot portions of the code using the constructor “var array = new Array(num)” or setting the array length if declared with []
  3. do NOT pre-allocate big arrays (e.g. > 64K elements) to their maximum size, instead grow as you go.
  4. it’s best to use WebGL typed arrays (Uint32Array, Float32Array, Float64Array etc…)
  5. use contiguous keys starting at 0 for Arrays
  6. don’t delete elements in arrays, especially numeric arrays
  7. don’t load uninitialized or deleted elements:

I was quite intrigued by the possible performance increase obtainable by simply pre-allocating an array by specifying its size (var array = []; array.length = 1000; or simply var array = new Array(1000) ) so I created a test suite on JsPerf to test these assumptions, and it turns out that Chromes doesn’t really behave as expected, despite being the fastest browser out there anyway.

Test setup:

I setup a two-parts test, as IE 9 doesn’t support typed arrays (and I don’t have access to IE10 yet).
The first part tests the performance differences between pre-allocating and not pre-allocating arrays, and also the difference between array declaration styles
var arr = []
var arr = new Array()
The second part tests typed arrays.

Test part 1

Test results: Chrome is the winner

Test results: Chrome is the winner

The figures tell us that Chrome is by far the fastest browser in this test, with Chrome v26 being more ~3x faster than Firefox v17.0.
Let’s now take a look at the assumptions 1 and 2 stated above and see if they are still true when put to the test:
As expected from assumption 1, Chrome is indeed at least 3x faster when pre-allocating a small array (with 1000 items), whereas on Firefox and IE 9 there isn’t any significative difference, with Firefox v17 being more 4x faster than IE 9!
On the browsers tested so far it makes no big difference using the alternative syntax
var arr = new Array(l) vs var arr = [l], although using the constructor is slightly faster on Chrome (especially on Chrome v26) and Firefox.

What about arrays with more than 64k items?
Unsurprisingly Chrome behaves in a different manner than the other two browsers: IE and Firefox do not show any remarkable difference about pre-allocated vs not initialised arrays, with a size of 65000 items. Chrome instead, as expected by assumption 2, performs ~3x faster when the array is not initialised and we are using var arr = []; array initialisation code.
But with much surprise this is not the best performing case, in fact this tests reveals that pre-allocating a big array using the constructor var arr = new Array(65000)  shows that Chrome is ~3x times faster!
Therefore we cannot say assumption 2 is always valid, as we see here that using Array constructor does a lot of difference.
The reason is not clear to me, given that the not-initialised cases (with new Array() and []) perform closely.
And we are not done with the surprises yet!

Test part 2
In fact if we take a look at the test about typed arrays, defined here as following

l = window.growFactor;
var arr =  new Uint32Array(l);
for (var i = 0; i < l; ++i) {
 arr[i] = 0;

shows again Firefox and Chrome performing in a significant different manner: the first benefits a lot by using a typed array (as expected), increasing performance by 2.5x, whereas Chrome sees its performances halved! As a result, Firefox’s performance peek almost matches Chrome’s peek.
Again, it is not clear to me why, I just think this is an oddity that is worth sharing.

We have seen that sometimes browsers performs in an unexpected way (see Chrome with typed arrays), and their performances may differ so much one from the other in things that look trivial and meaningless.
Therefore if your Javascript application is using arrays and needs to squeeze every drop of performance out of the engine, it may be worth spending some time to make some tests as the performance increase can be very significant!