Are native map, filter, etc. methods optimized to operate on a single intermediary array when possible?

Question

Consider the below snippet, which converts an array of objects to an array of numbers, with negative values filtered out, and then doubled by 2:

var objects = (new Array(400)).fill({
    value: Math.random() * 10 - 5
});

var positiveObjectValuesDoubled = objects.map(
    item => item.value
).filter(
    value => value > 0
).map(
    value => value * 2
);

When chained together like this, how many actual Array objects are created in total? 1, or 3? (excluding the initial objects array).

In particular, I'm talking about the intermediary Array objects created by filter, and then by the second map call in the chain: considering these array objects are not explicitly referenced per se, are Javascript runtimes smart enough to optimize where possible in this case, to use the same memory area?

If this cannot be answered with a clear yes-or-no, how could I determine this in various browsers? (to the best of my knowledge, the array constructor can no longer be overridden, so that's not an option)

Answer 1

Good commentary so far, here's a summary answer: an engine might optimize for memory usage across chained method calls, but you should never count on an engine to do optimization for you.

As your example of chained methods is evaluated, the engine's memory heap is affected in the same order, step by step (MDN documentation on the event loop). But, how this works can depend on the engine...for some Array.map() might create a new array and garbage collect the old one before the next message executes, it might leave the old one hanging around until the space is needed again, it might change an array in place, whatever. The rabbithole for understanding this is very deep.

Can you test it? Sometimes! jQuery or javascript to find memory usage of page, this Google documentation are good places to start. Or you can just look at speed with something like http://jsperf.com/ which might give you at least an idea of how space-expensive something might be. But you could also use that time doing straightforward optimization in your own code. Probably a better call.