JS Performance — Why is this loop slowing down?

Why This Question Matters

At first glance, the code snippet looks like a standard loop. You create an array, you loop through it, you time it. Easy, right? But for senior developers, this is a red flag.

The real issue isn't the loop itself—it's how JavaScript engines (like V8) handle memory and types under the hood. Most developers treat arrays as simple lists, but in JS, arrays are objects. Depending on how you initialize them and what you put in them, the engine might switch from a fast, contiguous memory block (like a C array) to a slow, hashed dictionary.

If you don't understand "elements kinds" or how the JIT compiler optimizes loops, you'll write code that works fine in development with 10 items but crawls to a halt in production with 10,000.

Understanding the Code

Let’s look at the snippet:

const bigArray = new Array(1000000).fill(0)
console.time("loop")
for (let i = 0; i < bigArray.length; i++) {
  // process bigArray[i]
}
console.timeEnd("loop")

Here, we're allocating a massive array of one million elements and filling them with zeros.

Internally, when you use .fill(0), you're telling the engine that every single element in this array is a small integer (Smi). V8 loves this. It can allocate a contiguous block of memory and optimize the loop because it knows exactly what type of data it's dealing with.

However, the performance concern kicks in the moment you start *processing* that data. If your "process" logic accidentally changes the type of an element—say, changing a 0 to a string or an object halfway through—you trigger a "deoptimization." The engine has to throw away the optimized machine code and fall back to a slower, more generic way of accessing the array.

Finding the Correct Answer

The question asks what the output is and why it's a performance concern. While the exact time output varies by machine, the core of the answer (Option B) focuses on memory allocation and the potential for "holey" arrays or type switching.

Why is this the right answer?

1. Allocation Overhead: Creating a million-element array isn't free. It puts immediate pressure on the heap.
2. The "Holey" Problem: If we had used new Array(1000000) without the .fill(0), we would have a "holey" array. A holey array is basically a skeleton; the engine can't optimize it as well because it has to check if an index exists before accessing it. By using .fill(0), we've avoided holes, but we've introduced a massive memory footprint.
3. Cache Misses: Iterating over a million elements can lead to cache misses. If the array is too large to fit in the CPU cache, the processor has to keep fetching data from the main RAM, which is significantly slower.

Other options usually fail because they focus on the for loop syntax itself. A for loop is actually one of the fastest ways to iterate in JS—much faster than .forEach() or .map() in many engines. The bottleneck isn't the loop; it's the data structure.

Common Mistakes Developers Make

The most common mistake I see is the "blind trust" in high-level methods. Developers often think .fill() or .map() is the "modern" and therefore "better" way. In reality, when dealing with millions of entries, the overhead of function calls inside a .forEach() adds up.

Another trap is Type Pollution. Imagine this:

const data = new Array(1000000).fill(0);
data[0] = "oops"; // The array is no longer "Smi" (Small Integer)

The moment you put that string in there, V8 might change the internal representation of the array from PACKED_SMI_ELEMENTS to PACKED_ELEMENTS. This transition is expensive and can make subsequent reads slower.

Lastly, people forget about Garbage Collection (GC). Allocating a million elements creates a giant object on the heap. When that array finally goes out of scope, the GC has to work overtime to clean it up, which can cause "stutter" or "jank" in your application's UI.

Real-World Usage

You won't often see new Array(1000000) in a simple React component, but you'll see this pattern in:

- Data Visualization: Processing large CSVs or JSON dumps for charts.
- Image Processing: Manipulating pixel data (where you should actually be using Uint8ClampedArray instead of a regular array).
- Game Dev: Handling entity lists or physics grids.

If you're doing heavy numerical work, stop using standard arrays. Use TypedArrays (like Int32Array or Float64Array). TypedArrays allocate a single, contiguous block of memory outside the regular V8 heap, avoiding the "type switching" problem entirely and drastically reducing GC pressure.

Key Takeaways

- Avoid "Holey" Arrays: Always initialize your arrays. A new Array(100) without a fill is a performance landmine.
- Watch Your Types: Keep your arrays homogeneous. Mixing integers and strings in a large array kills optimization.
- Use TypedArrays for Big Data: If you're handling millions of numbers, Float64Array or Int32Array is the only way to go.
- Loop Choice Matters: For extreme performance, a standard for loop is still king over functional iterators.