v8-memoryAnswer last reviewed July 2026

Here's one that surprises people. Two functions with identical code can differ in performance by an order of magnitude in V8. What are hidden classes and inline caches doing to make that happen?

A strong answer explains shape-based access and IC transitions with the actual cost model, and knows where shape pollution comes from in real services

What an AI-prepared candidate might say

So V8 creates hidden classes that describe the structure of an object, which properties it has and where they sit. Objects built with the same properties in the same order share a hidden class, and that lets V8 read properties at fixed offsets instead of doing dictionary lookups. Inline caches remember which hidden class a piece of code has seen at a given property access, so the next access with the same shape stays fast. When a call site sees a lot of different shapes it becomes megamorphic and falls back to slower generic lookups. That's how two identical functions end up so different, I think. One gets objects with a consistent shape and keeps its fast path, the other gets mixed shapes and loses its optimizations. The standard advice is to build objects with a consistent structure, same properties, same order, especially in hot code paths.

Senior
Locked

Maps and transition trees, the IC states from monomorphic through megamorphic with the real lookup cost at each tier, and what dictionary mode actually does.

Unlock the depth
Staff
Locked

Where shape pollution really comes from in API services (rows, optional fields, mutating middleware), the profiling workflow that finds it, and when to just leave it alone.

Unlock the depth
Follow-up chain
Here's one that surprises people. Two functions with identical code can differ in performance by an order of magnitude in V8. What are hidden classes and inline caches doing to make that happen? | NodeBook