Use of JavaScript new Array(n) Declaration

Question

Basic JavaScript question: Since there is no hard limit for arrays as the case with Java (i.e. IndexOutOfBoundsException), what is the use of the declaration where we specify the length property?

var a = new Array(10);

I know it predefines the length and puts "undefined" into those empty spots. Is that reason enough for having it?

• james: This is obviously an old post and so behaviour may have changed, but i think it's worth clarifying that the slots aren't filled with undefined, they're actually empty (i.e [,,,,,]). See developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/… (Note: this implies an array of 7 empty slots, not slots with actual undefined values).
• james: This subtle difference means that although the new Array has the specified length, you can't actually use any of the Array iterator methods to iterate over that array. i.e. var a = new Array(5).map((value, index) => index); does not set a as [0, 1, 2, 3, 4] it remains as [,,,,,]. So although fill, filter, every etc work as expected, it's easy to get caught out by the fact that map, forEach etc do not.
• james: A solution to this is to use Array.from(Array(10)).map((arg, index) => index)
• Quentin 2: This is often used by C# programmers who are confused about Javascript's Arrays and think this will fix the size of the array.
• gmoniava: @james I agree with your first comment. I think it should be noted that they aren't filled with undefined.

Answer 1

There are many perceived benefits of declaring an array size, but I think the majority of the perceived benefits are just FUD being passed around.

Better performance!/It's faster!

As far as I can tell the difference between pre-allocating and dynamic allocation is negligible.

More interestingly, the spec does not state that the array should be set to a pre-allocated length!

From Section 15.4.2.2 ECMA-262:

If the argument len is a Number and ToUint32(len) is equal to len, then the length property of the newly constructed object is set to ToUint32(len). If the argument len is a Number and ToUint32(len) is not equal to len, a RangeError exception is thrown.

An unscientific for-fun test case is here: http://jsbin.com/izini

It makes for more understandable code!

Personally, I disagree.

Consider the javascript you have written in the past, and consider code you may have to write in the future. I can't think of a single time where I've needed to specify a static limit on one of my arrays. I'd also argue that the potential problems of limiting arrays in javascript highly outweigh the benefits caused by letting people know what you were thinking with no actual checks behind it. Lets weigh the pros and cons...

Pros:

1. It will be easier for them to understand what you intended the code to do.
2. They will be able to find the bugs caused by your assumption later on (tongue firmly in cheek)

Cons:

1. Quick glances can easily confuse "new Array(10)" with "new Array('10')" which do entirely different things!
2. You are imposing an arbitrary limit on code with no normal length limit causing you to write lots of boiler plate code to check and maintain the limit.
3. You are imposing an arbitrary limit on code which could probably have been generalized to work with any length of values.
4. You're making an assumption about how people will read your code while assuming that the alternative would be less confusing.

You may as well have written:

//I assume this array will always be length 10
var arr = new Array();

In the above case the comment might even be preferable. The explicit declaration of intent can avoid any confusion not used to using the constructor as a declaration of intent.

Fine then.. why do you think it's even there then?

Convenience. When they were writing the spec I think they realized two things.

1. This sort of assignment would be something developers coming from similar languages would be used to.
2. Implementations of ECMAScript might potentially use it for performance gains.

So they put it in there. The spec only defines the use of the parameter, not how it should be implemented.

• Codesmith: I think the only thing I found that it's really very useful for is to create a string repetition function: function(s,n) {return Array(n+1).join(s);}
• rustybeanstalk: gamealchemist.wordpress.com/2013/05/01/… has some great performance explanations.
• Dewi Morgan: It's also useful for stuff like: palette8Bit = new Array(256); palette4Bit = new Array(16); ... which I would argue absolutely DOES improve code clarity, even if JS prevents rigorous enforcement of that dimension without extra nonsense.
• coderjoe: @DewiMorgan you're not wrong. The javascript landscape has changed significantly since this post was originally authored (almost 6 years ago exactly... WOW!). I wouldn't be surprised if the various javascript VMs were optimized for these cases now too. I still argue that the "improved readability" aspect of the array is still largely a factor of the type of team you're on and the javascript coding standards they use but... well... you're definitely not wrong. :)
• Cazineer: This answers is ancient and totally false. In Node, I can initialize an array const s = new Array(10000000) and do 10 million inserts and with the array literal [] it takes 23.6 seconds and with the constructor, 5.5 seconds.

Answer 2

Performance on the V8 JavaScript engine.

By doing:

var arr = []; arr.length = 1000;

V8 will preallocate the required memory for the array and maintain/set the array's Hidden Class to compact SMI (Small Int, 31 bits unsigned) array. However, this is not true when the desired length is too big, which results in the HC being set to sparse array (i.e., map).

Try the following link on Chrome: http://jsperf.com/0-fill-n-size-array

I've included an extra test case without the array length definition so you can tell the actual performance difference.

Related info: http://www.youtube.com/watch?v=UJPdhx5zTaw

Answer 3

Clarity.

When writing code, your goal is not so much for the computer to understand you, but for the next programmer that reads your code to understand you.

var xs = new Array(10);

The above code shows your intention: to have a 10 element array.

var xs = [];

The above gives nothing away; no extra information.

Cheers.

• SolutionYogi: var xs = []; tells you that number of items which will be stored in this array is not fixed. [It could be dependent on user input for example]

Answer 4

I am not sure, but I would bet it allocates memory differently at a low level. If you know you're creating 10,000 items, just reserve that much space rather than dynamically having it resize it in the background all the time.

• Dennis C: You can save no more then 1ms for preallocate 10,000 sized Array.
• bharal: if every second counts, doesn't every ms count 1000 times more?
• 15ee8f99-57ff-4f92-890c-b56153: If you're not sure, why are you betting?
• David Sergey: There is no prior knowledge about data type though, how would array know how much memory to allocate. It doesn't know if I'll store numbers or other arrays...
• rooby: @bharal: No, every ms would count 1000 times less.

Answer 5

Suppose you want an array of a certain length initialized to a certain value. This will not work:

scores = [].fill(0.0, 0, studentCount);

It'll just give you an empty array, because fill() will never extend the array beyond its original length.

This will work:

scores = new Array(studentCount).fill(0.0, 0, studentCount);

It'll give you an array of studentCount values initialized to zero.

Answer 6

I've created this JSPerf which demonstrates the problem, including it's various versions. Arguments I find are such:

1. Using new Array() can behave unexpectedly, can be overridden
2. Setting .length doesn't actually increase the array size in some browsers
3. The performance hit isn't really there.

I think these tests should put those arguments to rest, but it should be noted that different browsers treat this problem very differently. Firefox seems to optimize and figure out how large the array will be, while Chrome allocates memory as one would expect. And, as usual, Internet Explorer just stinks at the task.

Answer 7

Well, personally i want a queue. I want the queue to be length of 10.

The easiest way to do this is to use the push array method to put items onto the end of the queue, and the shift() method to get them off the front of the array.

The problem is, if i want to make a simple "add" method to my queue, and i write it up like so:

function addItemToArray(item, array){
 array.shift();
 array.push(item);
 return array;
}

then Nothing Good happens. What is better (actually, what will work) is to declare my array like this:

var maxSizeIsTen = new Array(10);

and then use it everywhere. Also, note the "nice" way of describing the array - no comments that nobody reads, and anybody using this code will work out in short order the max size of this array.

YAY!

• ZachB: I don't know what you expect this to do. Your maxSizeIsTen array can contain more than 10 elements. In many other languages if you try to add more elements to a fixed-size array you'll get an error; an element won't disappear as I gather you want it to.
• bharal: huh. i was scratching my head wondering what i was on about here - i think i have it, but didn't explain it neatly in the answer. IF you are using an array for a queue, AND you want the queue to have a fixed size, then you will want to use the new Array(someSize) command. I suppose you could sit and write "undefined" a whole bunch of times, but that's stoopid. In the answer, i'm suggesting that IF you are using a similar method as addItemToArray to maintain the queue, then you need to have the array size preset (or you just have a queue of size one).
• ZachB: Maybe, but I can't think of any situations where it's preferable to have a bunch of undefined elements that you'd have to shift through and have your downstream code know how to handle. Call push on your blank array 10 times and you have an array of length 10.
• bharal: Ho! Circular array used as a queue. You care less for what it is full of - you know what the entry point of the queue is. That's actually how i came on this question anyway, i had to implement one for performance reasons and was looking for the syntax.

Answer 8

Its not hard to maintain array size. Take a look on following example :

function updateArray(){
 var a = [1,2,3,4,5,6,7,8,9,10]; //original array object
 var b = [11, 12, 13]; //New array object to be pushed
 a.splice(a.length-b.length, a.length);
 a.unshift.apply(a, b);
 return a;
}

a.unshift.apply(arg1, arg2) push the new element on top and a.push.apply(arg1, arg2) at bottom.

Answer 9

As all of the answers with actual benchmarks no longer load, I created a new benchmark: https://jsbench.me/hhlk3jgvu4/1

The results on Chrome on macOS as of July 2023 are:

1. fillArrayWithSetLen 19K ops/s
2. fillArrayWithLenConstructor 18K ops/s ( 2.87% slower)
3. fillArrayWithLiteral 17K ops/s (11.71% slower)
4. fillArrayWithPush 15K ops/s (20.36% slower)

A second run with a randomized order yielded the same relative ranking:

1. fillArrayWithSetLen 19K ops/s
2. fillArrayWithLenConstructor 19K ops/s ( 1.98% slower)
3. fillArrayWithLiteral 16K ops/s (15.58% slower)
4. fillArrayWithPush 16K ops/s (19.85% slower)

Code in case the benchmark site disappears:

const testLen = () => {
 const rand = Math.random();
 return rand < 1 ? 4192 : rand;
}
const fillArrayWithPush = (len) => {
 const ar = [];
 for (let i = 0; i < len; i++) {
 ar.push({x: i, y: i + 1, z: i + 2, str: `str${i}`});
 }
 return ar;
};
const fillArrayWithLenConstructor = (len) => {
 const ar = new Array(len);
 for (let i = 0; i < len; i++) {
 ar[i] = {x: i, y: i + 1, z: i + 2, str: `str${i}`};
 }
 return ar;
};
const fillArrayWithLiteral = (len) => {
 const ar = [];
 for (let i = 0; i < len; i++) {
 ar[i] = {x: i, y: i + 1, z: i + 2, str: `str${i}`};
 }
 return ar;
};
const fillArrayWithSetLen = (len) => {
 const ar = [];
 ar.length = len;
 for (let i = 0; i < len; i++) {
 ar[i] = {x: i, y: i + 1, z: i + 2, str: `str${i}`};
 }
 return ar;
};

• ptoinson: This turned out to be the fasted for me (chrome, macos m1 pro).... const fillArrayRevWithSetLen = (len) => { const ar = []; ar.length = len; for (let i = len - 1; i >= 0; i--) { ar[i] = {x: i, y: i + 1, z: i + 2, str: str${i}}; } return ar; }
• Luis Paulo: @Joe that benchmark is riddled with bugs and thus misleading. I've forked yours: jsbench.me/lnlz2o3svm/1 For array above ~2k elements the way we instantiate the array doesn't matter because the JS engine doesn't eagerly allocate memory nor does it deallocate. It will use memory pools, lazy capacity increase and other heuristics and to optimize memory consumption. I also noticed Firefox performs better with assignments whereas Chrome is better with .push().
• Luis Paulo: Both Firefox and Chrome have similar performance on the preallocated array vs an empty array (with the empty array actually being faster sometimes), with Firefox being better with assignments and Chrome with Array::push. My suggest is to use the most expressive one: if you know the size beforehand, use the constructor for code clarity, not for performance; if you don't know the size of the array, don't preallocate and just push (Chrome has a bigger user-base) to an empty array. JS engines are very smart and written by very smart people. I didn't expect the empty array to behave so well!
• Luis Paulo: Btw, your bugs: - in testLen, Math.random returns a double-precision floating number between 0 (inclusive) and 1 (exclusive), so checking if that's less than 1 is always true. - the setup block helper says it runs before every loop, so generating the array length there is better to not affect the test's timing; - your fillArrayWithPush function allocates an array and then pushes, so that test is actually testing an allocation of double the expected size, hence the big differences in the results.
• Joe: I fixed the push bug. The random trick is to hide the constant array value as a weak attempt to prevent v8 from seeing a constant array size. The use case I'm testing is filling a new array, so I want to measure array initialization.