-1

I currently have code similar to this:

var someArray = new Array();
someArray[0] = "stuff";
someArray[1] = "things";
someArray[10] = "more stuff";
someArray[20] = "other things";
someArray[100] = "far away stuff";

and so on.

If I do this, will there be memory allocated for indices 1-9, 11-19, and 21-99? Is the amount significant enough to worry about if this array added information at 10,000, or some other high number?

I know you can do something like

someArray["ABC"] = "foo";

And this then treats it like a property on an object named someArray, that would also be used like

someArray.ABC = "foo";

So would this case be the same?

Tylor
  • 134
  • 5
  • 4
    Depends on how the engine implements arrays! Maybe this helps (for V8): http://www.html5rocks.com/en/tutorials/speed/v8/ – Felix Kling Oct 14 '14 at 15:40
  • Fact is, if you want to know what's really going on, you either have to read the source code of the engine, or (for some quick results) perform some memory profiling. – Felix Kling Oct 14 '14 at 16:00
  • I've just tried a simple profiling in Chrome, looks like (at least in Chrome) there is not any reserved allocated memory for the uninitialized elements. – King King Oct 14 '14 at 16:06
  • http://stackoverflow.com/questions/1510778/are-javascript-arrays-sparse – epascarello Oct 14 '14 at 16:23

2 Answers2

0

Edit: apparently this answer was a bit too terse/fuzzy for some.

As I previously stated, the memory allocation behavior in your example is unspecified. That is, the the ECMAScript specification doesn't tell engines how much memory to (not) allocate for unassigned array slots.

What really happens under the hood, then, varies a lot by engine. For example, a given engine may choose to pre-allocate 100bytes of memory for all new arrays with the assumption that they will be packed, and then subsequently de-opt into a sparse array implementation if a certain ratio of assigned values to array size isn't met. That's all up to the discretion of the engine implementors though, since, again, the language specification is silent here.

That being said, array sparsity is a rather critical concept to the language itself (despite memory allocation thereof being unspecified). For example, the specifications for several of the built-in Array.prototype methods (such as .map() and .forEach()) do explicitly define iteration behavior over "holes" in arrays (that is, indices that have never been assigned to). Additionally, real-world code often takes advantage of array sparsity as well. These factors all put a lot of pressure on engine implementors to not have their engine fall over and die when encountering code like:

var arr = [];
arr[4294967295] = 'allocate this';

In fact, go ahead and try it. You'll notice that any engine worthy of note (V8, Nitro, SpiderMonkey, Nashorn, Rhino, Chakra, etc.) handle it just fine.

Now, why it works in each of these engine is it's own discussion, but summarily speaking, it's because they all expect, and can adequately cope with, sparse arrays.

jmar777
  • 38,796
  • 11
  • 66
  • 64
  • Can you provide a link to the *official* specification? – Artjom B. Oct 14 '14 at 15:39
  • @GameAlchemist What more specifically needs to be said? It's simply a fact that the specification doesn't tell engines how to implement sparse arrays. It's also a fact that virtually all modern engines deal with array sparsity rather efficiently too. – jmar777 Oct 14 '14 at 15:43
  • @GameAlchemist that is incredibly picky. I'm open to criticism on the *exact semantics* of what I said, and happy to fix, but the answer is technically correct. And *obviously* the link I threw out there says nothing about sparse array performance, because my *entire point* is that the specification *doesn't say anything about sparse array performance optimizations*. – jmar777 Oct 14 '14 at 16:07
  • @GameAlchemist I expanded my answer. But honestly it still boils down to: 1) the specification doesn't say what to do in this situation, and 2) noteworthy JavaScript engines all optimize for this in some way, shape or form. Which is ultimately the truth here and directly addresses the question. Arguing over whether "officially undefined" was as accurate as "not specified" is just plain silly, "in general" was idiomatically accurate, and "pretty efficient" is clearly in relation to pre-allocating for every possible array slot. `/me shrugs shoulders, gets back to my Tuesday...` – jmar777 Oct 14 '14 at 16:30
  • 1) "you didn't even mention the key aspect of all this". That wasn't a key aspect at all. The question was type-agnostic and about sparse arrays, not about optimizations for packed arrays of uniform types. 2) "it can be optimized to a plain C++ array". This goes so far down the implementation-specific rabbit-hole it only enforces my point. 3) "That's why one should't use sparse arrays". Way too general of a statement; sparse arrays can be incredibly useful in the right context. 4) "which will be treated as a hashmap". *Maybe.* Again, very implementation-specific. – jmar777 Oct 14 '14 at 16:57
  • @GameAlchemist Delete what you want. I'm still open to actual criticisms about my answer; if it can be improved, awesome. Done feeding this particular troll, though. – jmar777 Oct 14 '14 at 17:14
-2

In general there shouldn't be a big waste of memory, because when you have

var someArray = new Array();
someArray[0] = "stuff";
someArray[1] = "things";
someArray[10] = "more stuff";
someArray[20] = "other things";
someArray[100] = "far away stuff";

and then do this:

alert(someArray[2]);

The result would be null/undefined. Allocated memory is not undefined, it would be an empty String.

There is a very detailed description to your problem here on stackoverflow i guess, but i had no time reading it. Check it out, maybe it helps you.

Detailed Description

Community
  • 1
  • 1
Sebastian Weiß
  • 349
  • 4
  • 14