Diving deep into JavaScript array – evolution & performance

Before starting the article I would like to state that this is not about the basic of JavaScript array. Neither about teaching syntaxes or showing usage examples. The article is more about memory representation, optimization, behavior differences over syntaxes, performance and the recent evolution.

When I started using JavaScript for the first time; I was already familiar with C, C++, C# etc. And trust me like many other C/C++ people, I also didn’t have a good first date with JavaScript.

One of the major reasons why I didn’t like JavaScript was, its Array. As JavaScript arrays are implemented as hash-maps or dictionaries and not contiguous, I was feeling like this is a B grade language; can’t even implement an array properly. But since then both JavaScript and my understanding with JavaScript has changed… a lot.

Why JavaScript arrays are not actual arrays

Before stating something about JavaScript, let me tell you what is an Array.
So, arrays are a bunch of continuous memory location, used to hold some values. Here the emphasis is on the word continuous or contiguous; because this has a significant effect.

Array memory representation

An memory representation of an array has been provided in the picture above. So it is made to hold 4 elements of 4 bits each. Thus it is taking 16 bits memory blocks, all in the same order.

Suppose, I’ve declared tinyInt arr[4]; and it has captured a series of memory blocks, starting from address 1201. Now at some point if I try to read a[2], what it will do is a simple mathematical calculation to find out the address of a[2]. Something like 1201 + (2 X 4) and will directly read from address 1209.

linked list javascript

In JavaScript, an array is a hash-map. It can be implemented using various data structures, one of them is linked-list. So in JavaScript if you declare an array var arr = new Array(4); it will make a structure like the picture above. Thus, if you want to read from a[2] any any point in your program; it has to traverse starting from 1201to find the address of a[2].

So this is how JavaScript arrays are different from actual arrays. Obviously a mathematical calculation will take way lesser time than an linked-list traversal. For long arrays, life will be more tough.

Evolution of JavaScript arrays

Remember the days when we used to feel jealous if a friend gets 256MB RAM in his computer? But today, 8GB RAM is a common thing.

Just like this, JavaScript has a language also have evolved a lot. With the immense effort from V8, SpiderMonkey, TC39 and the growing number of web users, JavaScript has become a necessity for the world. And performance improvement is an obvious need if you have a huge user base.

JavaScript engines these days actually allocate contiguous memory for its arrays; if the array if homogeneous (all elements of same type). Good programmers always keep their array homogeneous and JIT (just in time compiler) taking the advantage of that does all its array reading calculation just like the way C compiler does.
But, the moment you want to insert an element of different type on that homogeneous array, JIT de-structure the entire array and recreate with the old-days style.
So, if you are not writing bad codes, JavaScript Array objects maintains an actual array behind the scene, which is really great for the modern JS developers.

Not only that, the arrays have evolved even more with ES2015 or ES6. TC39 decided to include typed array in JavaScript and thus; we have ArrayBuffer with us today.
ArrayBuffer gives you a chunk of contiguous memory chunk and let you do whatever you want with it. However, dealing directly with memory is very low level and more complicated. So we have Views to deal with ArrayBuffer. There are already some views available and more can be added in future.

If you want to know more about the usage of Typed Arrays in JavaScript, you can go through the MDN Documentation.

Typed arrays are performant and efficient. It was introduced after the request from WebGL people, as they were facing immense performance issues without a way to handle binary data efficiently. You can also share the memory using SharedArrayBuffer across multiple web-workers to get a performance boost.
Amazing right? It started from simple hash-maps and now we are dealing with SharedArrayBuffer.

Old Array vs Typed Array – performance

We’ve talked a lot on array evolution in JavaScript. Now let’s check how beneficial are the modern arrays. I have done some small tests here and all are done with Node.js 8.4.0 on Mac.

Old Array – insertion

Time taken: 55ms

Typed Array – insertion

Time taken: 52ms

Damn, what am I seeing? The performance of old traditional array and ArrayBuffer are same? Nope. Remember, I told before that the compilers these days are smart and converts the traditional array to an actual contiguous memory array internally, if it’s homogeneous. That’s exactly what happened here in the first example. Though I used new Array(LIMIT), then also it was maintaining a modern array in it.

Now let’s modify the first example and make it a heterogeneous array and let’s se if there’s any performance difference.

Old Array – insertion (heterogeneous)

Time taken: 1207ms

All I have done here is, added a new expression in line no. 3 to make the array heterogeneous. Everything else is exactly same as before. But see the performance difference. It’s 22 times slower.

Old Array – read

Time taken: 196ms

Typed Array – read

Time taken: 27ms


Introduction of typed array in JavaScript is a great step. Int8Array, Uint8Array, Uint8ClampedArray, Int16Array, Uint16Array, Int32Array, Uint32Array, Float32Array, Float64Array etc are typed array views, who are in native byte order. However, you can also check DataView to create your custom view window. Hope in future we will find more DataView libraries to use ArrayBuffer with ease.

It’s nice to see arrays have been improved in JavaScript. Now they are fast, efficient, robust, and smart enough while allocating memory.

About This Author

Hello! I am Paul Shan, a JavaScript Expert, Full Stack and DevOps Engineer cum Consultant based out of Bengaluru, India.

  • Rico Alexander

    Interesting article. One question I have is if there is a performance difference accessing values in a object with key pairs vs. accessing them in an array where you do findIndex to access the value. I like working with key pair objects because I can set the primary key of my db object to the key and access items with that primary key but that object doesn’t have a length property like arrays so I’m torn. Objects are also easy to concatenate and update.

    • Paul Shan

      Yeah, searching by keys will make the complexity to O(1) in case of objects, whereas in arrays it’s O(n). Obviously better. But that’s not practical everywhere. Many a times you just need that to be an array. And object keys are always string, but in array you can store anything. Length is not a problem, you can create a setter named length in it.

    • Rico Alexander


    • Mihail Malostanidis

      You may want to use the ES6 Map type.
      It doesn’t have the object’s gotchas, has consistently great performance, is good for iteration (iterates in key insertion order)

  • olgi3rd

    How did you know that js arrays are implemented as hash-maps? Did you read V8 source code? Where can I find related resources?

    • Paul Shan

      I think people know that. Majority of the articles also cover that.
      Simple example. var arr= [1,2]; arr.myVal = 20; This works in javascript.

    • olgi3rd

      Yes, Arrays are objects. Functions are also objects.

    • Paul Shan

      And JS objects are hashmaps. They are nothing but key value pair with complexity O(1). Thus hashmap.

    • olgi3rd

      I didn’t know that. Big O is difficult to me.

    • Mihail Malostanidis

      Hashmaps are typically sub-O(n) but can actually span the computational complexity range of O(1) to O(n) depending on hash collisions (which depends on the hashing function and key domain)

  • Luiz Alberto

    If I change arr.push({a: 22}); to arr[0] = {a: 22}; the timing is the same as typed arrays, even if it is a heterogeneous array.

    I think the big catch here is:
    – push is making the old arrays examples slow; or
    – add an item into a defined position of the array (arr[0] = …) is faster than push.

    Also the reading examples had almost the same amount of time (old read and typed array read).

    Don’t know if my observations are right. Would love a discussion about this.

    Nice post!

    • Paul Shan

      Yeah [0] may be faster than .push for various reasons. Depending on the engine (v8) development.
      But the performance difference should be same on both old and new array.

  • Mihail Malostanidis

    Of course JS Arrays and their indexes have to be exposed as object keys, for compatibility, but the native representation of [] (not accessible from JS) is actually quite different, for performance reasons. You can see it is probably a growable array because the memory allocation for the array is suddenly doubled at certain points. Not sure if it’s a proper array with the values being moved into the new allocation, or if the chunks are just linked.
    So it is also exposed via the Object (hashmap) interface for compatibility, but

  • Evan Moon

    Hi, Paul Shan. I am a frontend developer who working in South Korea 🙂
    I read your post very interestingly. I would like to translate this post into Korean and upload it on my blog if you allow it.
    Of course I will attach a link to this post in the my post.