Front-end and full-stack developers use JavaScript arrays every day. Most of them, however, haven’t done a deep dive to understand how JS arrays are implemented in native code.
Not doing this doesn’t mean you’re a bad developer. It’s entirely possible to use JavaScript effectively without digging in to understand how JS arrays are implemented. But taking a closer look can help you understand performance issues your might run into, so it’s a worthwhile exercise.
How exactly they are implemented depends on the specific JavaScript interpreter or VM you’re using. I’m going to use the V8 JavaScript engine (used by Chrme and Node.js) as an example. Other JavaScript engines, such as Mozilla’s SpiderMonkey and Microsoft’s Chakra will be similar but not identical.
JavaScript Arrays in V8
In V8, if your array only contains integers, it’ll be backed by a C++ array of integers. Typically, the backing array will be bigger than the number of integers it currently contains. If it contains a mixture of integers and floating point values or only floating point values, it’ll be backed by an array of doubles.
If the array contains only objects, or a mixture of numbers and objects, it’ll backed by an array of pointers. Even though JavaScript itself doesn’t have a concept of ‘integer’ or ‘double’ – it just sees them all as ‘number’, V8 keeps track and makes it so arrays are a bit faster and more memory efficient if you only put integers in them.
If you call push() when the backing array is full, it’ll allocate a new, bigger backing array, copy the existing elements over, and then add the new value you pushed. This is similar to the implementation of ArrayList in Java or vector in C++.
All of the above only is only sure to apply if your array is packed, and not sparse – i.e. you don’t have any gaps in the array. If you do something like
let abc = [1,2,3];
abc[100] = 50;you now have a sparse array. If is not too spare, it’ll still be backed by an array, with empty array indices replaced with a ‘hole’ value. If you look at V8’s C++ array source (linked below), you’ll see calls to element->is_the_hole(i). If an array is very sparse, it’ll no longer be backed by an array in memory. Instead, it will be backed by a dictionary/hashtable, and it’ll take longer to both access elements and iterate through the array.
If you’re interested, you can read through V8’s array implementation in C++ here. You’ll notice that it often checks the following constants:
PACKED_SMI_ELEMENTS– a packed integer arrayPACKED_DOUBLE_ELEMENTS– a packed double arrayPACKED_ELEMENTS– a packed object arrayHOLEY_SMI_ELEMENTS– a sparse integer arrayHOLEY_DOUBLE_ELEMENTS– a sparse double arrayHOLEY_ELEMENTS– a sparse object arrayDICTIONARY_ELEMENTS– a very sparse array that is backed by a dictionary
And you’ll see that it always tries to do whatever will be fastest for the array it is operating on. Lots of builtin functions like push, pop, shift, unshift, and concat do different things depending on the array’s density and what kind of elements it contains.
Some other things to keep in mind: if you have an array that only contains integers, and you push a floating point number or other type into it, it will be ‘downgraded’ for the rest of its life, even if you purge the non integers from it.
Also keep in mind that none of these implementation details are guaranteed. A naive implementation of JavaScript’s Array object could be backed by a linked list, and it would still work the same way it does now. It would just be slower.
Actually, if you grab an early copy of the Mozilla source code from 20 years ago, you’ll find that arrays were backed by ordinary JS objects without much optimization, just some extra code to handle special cases like the `length` property.
Digging Deeper
If you’re interested in diving even deeper into V8’s internals, I suggest starting by reading through the source files I linked to above. If you’re not used to C++, understanding it will be a bit of a chore at first.
I recommend sticking with it, though. Learning and understanding a new language is always good – and every extra insight you gain into how JavaScript VMs run your code will make you a more effective JavaScript developer.
If you liked this, you might like these other articles I’ve written:
Using Web Components with React in 2019
An Angular Roadmap – The Past, Present, and Future of Angular