Inline Caches: Monomorphic, Polymorphic, Megamorphic

The Lookup That Should Be Slow but Isn't

Think about this for a second. JavaScript is dynamically typed. When you write obj.x, the engine has no idea at compile time where x lives in memory. It could be an own property, a prototype property, a getter, a Proxy trap, or missing entirely. A naive implementation would search for x on every single access.

And yet -- V8 accesses obj.x in a tight loop at essentially the same speed as accessing a C struct field. How?

function getX(obj) { return obj.x; }

const point = { x: 10, y: 20 };

// After a few calls, this runs as fast as a C struct field access
for (let i = 0; i < 1000000; i++) {
  getX(point);
}

The answer is inline caches (ICs). They're the most important performance mechanism in V8, and they exist at every property access, function call, and operator in your code.

What Is an Inline Cache, Really?

So how does this actually work in V8? At the bytecode level, every property access like obj.x has an associated IC slot. The IC records what hidden class (Map) it has seen and where the property was found:

// Bytecode for: return obj.x;
LdaNamedProperty obj, "x", [IC_slot_0]

That [IC_slot_0] is the inline cache. It starts empty (uninitialized) and evolves through states based on what objects it encounters.

The Four IC States

The performance difference between these states is dramatic -- we're talking orders of magnitude:

In a loop running 10 million iterations, the difference between monomorphic and megamorphic is the difference between 10ms and 1000ms.

Monomorphic: The Fast Path

This is where you want to be. When an IC sees only one hidden class, V8 generates a fast path that looks like:

// Pseudocode for monomorphic IC at getX(obj):
if (obj.map === CACHED_MAP) {
  return obj[CACHED_OFFSET];  // Direct memory read at known offset
}
// Slow path: full lookup

This is a single pointer comparison followed by an offset read. On modern CPUs, this compiles to roughly 2-3 machine instructions.

class Point {
  constructor(x, y) { this.x = x; this.y = y; }
}

function sumX(points) {
  let total = 0;
  for (const p of points) {
    total += p.x; // IC sees one Map (Point), stays monomorphic
  }
  return total;
}

// All Points have the same Map — monomorphic, maximum speed
const points = Array.from({length: 100000}, (_, i) => new Point(i, 0));
sumX(points);

Polymorphic: The Middle Ground

When an IC encounters 2-4 different hidden classes, it becomes polymorphic. V8 builds a small lookup table:

// Pseudocode for polymorphic IC (2 shapes):
if (obj.map === MAP_A) return obj[OFFSET_A];
if (obj.map === MAP_B) return obj[OFFSET_B];
// Slow path

This is still fast — a few comparisons — but it's measurably slower than monomorphic in hot loops.

function getX(obj) { return obj.x; }

const point2D = { x: 1, y: 2 };
const point3D = { x: 1, y: 2, z: 3 };

// IC at getX becomes polymorphic (2 shapes)
getX(point2D);
getX(point3D);

Megamorphic: The Slow Path

And this is where things go off a cliff. Once an IC has seen 5 or more different hidden classes, V8 basically gives up. It transitions to megamorphic and falls back to a generic lookup that searches the object's Map descriptor chain.

function getX(obj) { return obj.x; }

// Five different shapes = megamorphic
getX({ x: 1 });
getX({ x: 1, a: 2 });
getX({ x: 1, b: 2 });
getX({ x: 1, c: 2 });
getX({ x: 1, d: 2 });

// This IC is now permanently megamorphic
// Even passing { x: 1 } again goes through the slow path

The Real-World Impact: Let the Numbers Speak

// Setup: 100,000 objects with identical shape
class UniformPoint { constructor(x) { this.x = x; } }
const uniform = Array.from({length: 100000}, (_, i) => new UniformPoint(i));

// Setup: 100,000 objects with 10 different shapes
const mixed = Array.from({length: 100000}, (_, i) => {
  const obj = { x: i };
  // Add a unique property based on i % 10 to create 10 different shapes
  obj['prop' + (i % 10)] = true;
  return obj;
});

function sumX(arr) {
  let sum = 0;
  for (let i = 0; i < arr.length; i++) sum += arr[i].x;
  return sum;
}

// uniform: ~0.3ms (monomorphic IC)
// mixed:   ~5ms   (megamorphic IC, ~16x slower)

Same number of objects, same .x access, 16x performance difference. Let that sink in. This is entirely caused by IC states.

Production Scenario: The Event Handler Slowdown

This one's a classic. A frontend app has an event normalization layer:

function handleEvent(event) {
  const x = event.clientX;  // IC for clientX
  const y = event.clientY;  // IC for clientY
  updateCursor(x, y);
}

// Called with MouseEvent, PointerEvent, TouchEvent (wrapped),
// custom synthetic events from drag library, test mock events...

Five+ different event shapes hit the same event.clientX access site. The ICs go megamorphic. On a 60fps animation driven by pointer events, this adds 2-3ms per frame — enough to cause visible jank.

The fix: normalize the shape at the boundary:

function normalizeEvent(event) {
  // Create a consistent shape before passing downstream
  return { clientX: event.clientX, clientY: event.clientY, type: event.type };
}

function handleEvent(event) {
  const normalized = normalizeEvent(event);
  // IC here is monomorphic — all normalized objects have the same shape
  updateCursor(normalized.clientX, normalized.clientY);
}

The trick is elegant: normalizeEvent absorbs the megamorphic cost (it's called less frequently), while the hot handleEvent path stays monomorphic.

Common Mistakes

Quiz: IC State Identification

Key Rules