The first step of performance work isn't profiling — it's answering one question: how many translations sit between the line of JavaScript in your head and the instructions the CPU actually runs?

Take const a = 3 + 4. Look at it with three different eyes. The same one-liner shape-shifts across three worlds, and every V8 optimization trick lives in the translation between them.

A bare CPU only speaks machine code, but JavaScript is dynamic — types are a runtime fact. Given add(a, b), I can't fold it down to a single add eax, ebx if I don't know what a and b are — next second you might pass me two strings.

So V8 inserts a bytecode layer between brain and CPU: closer to a real machine than the AST, more flexible than asm — interpretable, observable, and recompilable into machine code once V8 has watched enough calls to know what your types actually are.

That layer is the entire battlefield of JS performance work. The rest of this piece is about what V8 does in there — and how you can cooperate with it.

The hard part isn't editing code. The hard part is seeing what V8 is doing right now. So this piece doesn't tour every V8 internal — it answers one concrete question:

It's a perfectly ordinary helper. Input may be a number, a string, or a { value, unit } shape; output is a rem value. In one of our projects it ran hundreds of times per frame and burned non-trivial CPU.

The 19 chapters that follow are each one cut of making it faster. Pipeline, Hidden Class, Inline Cache — these aren't decorations. They are the knives we'll cut the problem with.

Static languages like C / Rust / Go can pin down types, call shapes, and memory layouts at compile time — so they take the AOT (Ahead-Of-Time) road. By the time the binary ships, almost no "compiling" happens at runtime.

JavaScript is dynamic. Until add(a, b) is actually called, nobody can promise the two arguments are numbers — they could be strings or objects. So V8 takes the JIT (Just-In-Time) road: it compiles while running, observes types, and re-optimizes from feedback.

It means the same chunk of JS gets recompiled while it runs — interpreter first (Ignition), then once V8 notices it's hot, baseline (Sparkplug), mid-tier (Maglev), and finally peak (TurboFan) take turns. Each upgrade burns milliseconds in compilation itself — a tax AOT languages never pay.

So when you write function add(a, b) { return a + b }, four different versions of add may have run inside V8 by the time you blink — each at a different level of optimization, each with a different set of assumptions.

That's also where the leverage sits: keep V8's assumptions stable and your function lives on the peak (TurboFan machine code) forever — never "deoptimized" back into bytecode interpretation.

V8 is not one compiler — it's a pipeline of four. The same function climbs the tiers as it gets called more often. Each tier emits code closer to the metal, runs faster, but costs more time to compile in the first place.

This is V8's core tradeoff: cold code isn't worth optimizing, hot code is worth optimizing harder. A function's "performance" isn't a single number — it's a curve that moves over time. This chapter is the map of that curve.

Because TurboFan's compile time is itself a performance cost — and TurboFan needs feedback to optimize well; without it, even TurboFan's output is mediocre.

In real apps, most code only runs a handful of times: a setup function on page load, a one-shot callback. Compiling those into TurboFan is a pure loss. So V8 uses a simple heuristic:

Three implications:

1. Performance is "after-N-calls" performance. Cold and steady-state numbers can differ by 5–10×; any benchmark must pre-warm the function for thousands of iterations before timing.
2. Deopt is the performance nightmare. One deopt drops a function from TurboFan machine code back to Ignition — like shifting from top gear straight to first. Ch7 covers how to avoid it.
3. Maglev makes small hot functions matter. Pre-Maglev, small hotspots sometimes never crossed TurboFan's threshold and stayed un-optimized. Maglev gave them a middle gear to hit.

"Bytecode" sounds like a magic word, but underneath it's plain: an instruction set for a virtual CPU. The only difference from x86/arm is that no silicon ships with a bytecode decoder built in.

Walk const a = 3 + 4 through V8 and you'll see it appear in two languages: first as Ignition bytecode, then as TurboFan machine code. Side by side:

V8's bytecode ISA is a stack machine with an accumulator. LdaSmi [3] means "Load Smi into accumulator"; Star0 means "Store accumulator into register 0". Two wins:

1. Compact encoding. Most instructions are 1–3 bytes — far tighter than a three-address IR. This matters for V8's start-up: the cold path runs in Ignition.
2. Simple dispatch. Each opcode has a handler; handlers chain through the accumulator. CPU-pipeline friendly and easy on branch prediction.

The cost is the interpreter loop: every instruction pays "fetch → decode → jump-to-handler → execute → jump-back". That loop alone is roughly an order of magnitude slower than running raw machine code. That's why Sparkplug exists — translate bytecode 1-to-1 into asm and kill the dispatch loop.

Real TurboFan output is much fatter than the three-line figure above. Run node --print-opt-code --allow-natives-syntax and you'll see a swarm of cmp / jne / test around the core. That's not logic — it's V8's checkpoint machinery (type guards) plus the calling convention scaffold.

The orange lines are type guards: they verify "is this still a SMI?" on every call. Pass → fall through to the green core add; fail → jump out to deopt. One line of JS becomes nine lines of asm — six scaffold, one logic.

That scaffold is the protagonist of Phase II: the assumption + feedback + checkpoint trio. It's why TurboFan is faster than Ignition and why breaking an assumption tanks performance — same coin, two faces.

That testb [rbx+0xf], 0x1 in the previous chapter is checking the lowest bit. This isn't V8-only — in C/C++ it's called a Tagged Pointer: stuff type info into a pointer's low bits instead of carrying a separate field. V8's flavor:

• low bit = 0 → it's a SMI (Small Integer, 31-bit signed). Read the value by shifting the high 31 bits one to the right.
• low bit = 1 → it's a HeapObject pointer. The real object lives on the heap; dereference required.

That single bit forks V8's handling of a 64-bit word into two completely different paths. Try lighting one up:

Because integers are everywhere. In a real page, the heap is mostly numbers — indices, pixels, milliseconds, coordinates, counters. Boxing every one of them into a HeapObject (with a hiddenClass, meta header, and GC bits) would drown V8 in memory traffic and pointer chasing.

Tagging SMIs with the low bit lets V8:

• Skip the heap for SMIs — they live in registers as immediate values; arithmetic is one CPU instruction.
• Reduce the type check to a testb — the "is it a SMI?" guard from the previous chapter is one cycle.
• Skip SMIs in GC — they aren't pointers, so the collector just moves past them.

Three direct, actionable consequences:

1. Use integers over floats when you can. 1.0 + 2.0 boxes into HeapNumber (slow path); 1 + 2 stays SMI throughout (fast path). Same for Math.floor(x) followed by arithmetic — V8 knows the result is an int and keeps it SMI.
2. Prefer numbers over strings as keys / switch values. In hot functions, replace obj['x'] with obj.x, and switch on integer enums rather than string literals — V8's check path becomes shorter.
3. Don't mix types in arrays. [1, 2, 'three'] escalates the whole array's elements kind to generic HOLEY_ELEMENTS — all reads/writes go through HeapObject paths. [1, 2, 3] stays in PACKED_SMI_ELEMENTS, where reads are raw memory accesses.

Tagged Pointer isn't a curiosity. It's the minimal decision V8 makes behind every line of JS you write.

Here's the real paradox: JS is dynamically typed, so how does V8 ever produce C-tight machine code?

Answer: V8 doesn't "know" — it guesses. It runs, watches the types your function actually sees, makes bold assumptions, and emits fast-path asm based on those assumptions — with type-check checkpoints inlined so it can throw the asm away the moment the guess fails.

The trio:

As a timeline:

The trio is invisible by default — until you flip V8's built-in switches. This is the first class of tool for analyzing slow JS:

Compose these switches and you can see what V8 is doing behind the scenes. The next chapter walks a real function through a deopt event.

Let's actually measure the "checkpoint fail → deopt" event from the previous chapter. The code below runs in three distinct performance regions, with a 3–5× swing:

Because V8 threw away the TurboFan machine code it had compiled in L1. L3's loop restarts in Ignition — the bytecode interpreter, an order of magnitude slower on its own. Eventually V8 re-compiles, but the feedback is now "polluted": it knows a/b can be either number or string, so the new assumption degrades to any+any, and the emitted asm has to carry extra type branches — fatter than the original mono-SMI version.

That's the real cost of deopt:

• Immediate: the discarded TurboFan code wasted milliseconds of compile time.
• Transient: thousands of interpreted calls in Ignition before re-tiering, each 5–10× slower.
• Lasting: the recompiled version is polymorphic; even its steady state is much slower than the original monomorphic version — that's why L3 is 3.6× slower than L1.

"reason: not a Smi" is the single most common smoking gun when chasing slow JS — it pinpoints which line, which bytecode offset, which assumption blew up. In Phase IV's main-line we'll use this exact log to backtrack issues line by line.

The previous chapter showed one add('a','b') triggering a deopt — but the truth is finer-grained. Each call site's FeedbackVector entry runs a state machine that degrades step by step as more type variations come through:

It's V8's engineering tradeoff. Each extra type branch adds a few cmp/jne lines to the asm — code grows, i-cache pressure grows. V8 benchmarked extensively and found that polymorphism up to 4 still beats the interpreter; beyond that, it's a net loss — fall back to generic dispatch.

So 4 is empirical, not physical. As an author you only need one rule:

Use %DebugPrint(fn) and find the feedback_vector section. You'll see something like:

BinaryOp::SignedSmall means you're golden (SMI mono); BinaryOp::Any means the slot has degraded to the worst case. This is the first diagnostic signal we'll reach for repeatedly in Phase IV's main-line.

What does "hot enough" actually mean? V8 codifies it in one function — v8::internal::TieringManager::ShouldOptimize. Let's read it:

1. L1 — already optimized code isn't re-optimized.
2. L3 — Maglev decision; constrained by maglev_filter (see --maglev-filter=name).
3. L8 — explicit disable / power-saver / efficiency mode skip optimization (e.g. node --v8-options="--turbo-filter=xxxxx").
4. L14 — must be called enough times to optimize. This is the threshold on the performance curve — your first thousand cold-start calls won't make it into TurboFan. There's also efficiency_mode_delay_turbofan to push tiering further out.
5. L18 — overly long functions are skipped. max_optimized_bytecode_size defaults to 60K bytecode bytes. That's why our first move in Phase IV will be function decomposition: break giant functions into small ones so each can be optimized.

We've covered V8's compile pipeline and assumption system. Now into the third — and most rewarding — block: the object memory model.

A thought experiment: it's 2008, you're on the Chrome V8 team, and your job is to lay JS objects out in memory. How would you do it? First, here's how C does it:

A static struct is one contiguous block of memory. The compiler knows x is at offset 0, y at offset 4 — property access is an O(1) offset load. But that rests on two assumptions you can't break:

1. The compiler knows which fields exist at compile time.
2. The struct is fixed-size; you can't add fields at runtime.

JS shatters both. obj.foo = 42 can graft on at any moment; delete obj.foo rips off at will. So you can't get away with "one mov per property read".

First instinct: if fields are dynamic, store them as [key1, val1, key2, val2 ...] and walk the array on every obj.x.

Two problems:

1. Lookup is O(n) — scan keys on every access.
2. Objects of the same shape duplicate the key strings: a million {x, y} objects means a million copies of "x" and "y".

The second one's lethal — a real Web app has tens or hundreds of thousands of identically-shaped objects. That's unacceptable bloat.

V8 chose this: every JSObject has three storage areas plus a pointer to a Hidden Class — and the Hidden Class itself is the "shape description". All same-shape objects share one.

1. No more key duplication. A million {x, y, z}s share a single set of "x"/"y"/"z" strings (inside the shared Hidden Class).
2. Property lookup can become O(1) — provided we know the object's shape ahead of time. Ch11 covers how Hidden Class records the shape; Ch13 covers how Inline Cache compiles it into asm offsets.

The price: change the shape, change the Hidden Class. Hence the central mechanism of Phase III — Transition Chain (next chapter).

"Hidden Class" is V8's term — internally, the V8 source calls it a Map (yes, the same Map you see in %DebugPrint). Edge Chakra calls it Types, JavaScriptCore calls it Structure, SpiderMonkey calls it Shapes. Every modern JS engine has the exact same thing under different labels.

The most important sub-structure inside a Hidden Class is the DescriptorArray — it records "this shape has these keys, and each key corresponds to this in-object slot index". Concrete example:

The crucial property: objects of identical shape share the same Hidden Class instance.

• const o1 = { x: 11, y: 22 } · Hidden Class A
• const o2 = { x: 33, y: 44 } · same Hidden Class A
• const o3 = { y: 11, x: 22 } · different Hidden Class B (order changed!)
• const o4 = { x: 11, y: 22, z: 33 } · Hidden Class C (extra key)

Note o3 vs o1 — assignment order is part of the shape. This underlies rule #4 of Phase IV: "keep property assignment order stable".

The previous chapter mentioned V8 has two places to store named properties: in-object (reserved inside the JSObject body) and the *properties array (overflow). The DescriptorArray in Hidden Class covers both — to you it's just obj.x, but V8 may take either path internally.

Which one? V8 reserves 4 in-object slots for an empty object (called Slack Tracking, see Ch20). The first 4 properties go in-object; later ones overflow into *properties. That's the foundation for Phase IV rule #5 ("declare class fields with defaults") — fill those slots immediately at construction.

The previous chapter said same-shape objects share a Hidden Class — but how does shape change? V8's answer: chain Hidden Classes into a transition chain. Each new property appends a node; objects that took the same path of insertions share the same chain node.

Click "+x", "+y", "+z" below to watch the chain grow:

The chain structure makes it obvious:

Two innocuous-looking blocks. In V8's eyes they point at two completely different Hidden Classes, and any function that takes either gets pushed into polymorphism. The most insidious trap in performance-critical code.

The fix is mechanical: initialize all fields up front, in a fixed order. React/Vue's internal instance pools deliberately preserve field order across components for exactly this reason — keep every instance on the same Hidden Class.

A chain only handles same-path growth. When two paths diverge, the Hidden Class becomes a tree with transitions:

Everything in Phase III leads here. Inline Cache (IC) is the steepest part of V8's performance curve — it can cut an obj.x access from O(n) string lookup down to a single mov. The gap is over 100×.

Real measurement, same "service discovery" function written two ways, 10M iterations:

When V8 compiles a property access with a static key like map.a, it follows the Hidden Class on first call to find "a"'s in-object offset (say, 1), then burns that number into the emitted asm:

That's Inline Cache in the flesh — it inlines "look up by key" into "first compare a Hidden Class pointer, then load a fixed offset". The name comes from this: the cache is inlined into the asm itself.

Contrast dynamic map[key]: V8 doesn't know the value of key at compile time, so each call has to:

1. compare the key string against every key in the Hidden Class;
2. then load the matched offset.

Even with V8's internal string interning (same string → same pointer; pointer-compare only), this is dramatically slower than one ldr. Hence the 145×.

ICs follow the same state machine as Chapter 8: uninitialized → monomorphic (after first call) → polymorphic (2–4 different Hidden Classes) → megamorphic (>4, cache abandoned). "Same shape" and "static key" are two faces of the same thing — IC only kicks in when both are true.

Everything so far has been Fast Properties — Hidden Class + IC compressing access into one ldr. There's one operation that kicks an object off the fast path entirely, demoting it to Slow Properties (dozens to hundreds of times slower).

That operation is delete.

Allowing delete opens three nasty cans of worms:

1. What happens to the freed in-object slot? Compact later ones into it → all other objects' pointers break. Leave it empty → all cached IC offsets are now wrong.
2. Other objects on the same Hidden Class — keep them pointing here, or fork? Keep → references go stale; fork → invalidate every IC pointing at the old class.
3. Every offset already inlined into TurboFan machine code needs re-emitting.

All three are hard. V8 picked the simple give-up plan: any object touched by delete degrades to Slow Properties — store properties in a dictionary (like Map<string, Value>) and abandon in-object + IC optimization.

Dictionary access is hash lookup — dozens to a hundred times slower than IC. And the demotion is one-way — once Slow, always Slow.

The previous 14 chapters were the knives. This chapter takes the main-line function and dissects it.

The function in one sentence: normalize any input (number / string / object) into a rem value. In our codebase it ran hundreds of times per layout frame; the profiler called it out as a hot spot:

All five trace back to one design mistake: one function handling three structurally different inputs. From V8's view, you've forced it to emit polymorphic asm for every property access and every binary op — the fast path never gets to form.

The fix is next chapter — split into three monomorphic functions and apply the rest of the 14 knives.

The following 12 rules aren't style preferences — each maps to a specific mechanism from the previous 14 chapters. I've ordered them by impact frequency on the main-line px2rem function — the top few cuts buy the most.

Click each rule's heading to expand its example.

The version after all twelve rules. The code is longer — but every function is monomorphic, field order is fixed, no delete, no dynamic keys:

No single cut is magic. Each one solves one specific V8 mechanism problem, and the small wins compound. As a ledger:

Mostly yes. The precondition is your bottleneck is actually JS execution. If it's DOM, compositing, network, or GC — that's a different mountain (each covered in different chapters of the chromium-renderer piece).

Quick check: open Chrome DevTools' Performance panel and see your hot function's share of frame time and color. JS-blue + over 5% means this methodology will almost certainly help.

This piece has been about V8, but those 12 rules are engine-agnostic. The reason: Hidden Class, Inline Cache, type feedback all trace back to 1991 Self research — every modern JS engine has independently implemented the same trio.

JSCore (WebKit's engine, used in iOS/macOS Safari) has a unique design: its peak tier FTL (Fourth Tier LLVM) compiles JS straight into LLVM IR and then runs full LLVM optimization passes — the same LLVM that ships C++/Rust/Swift, now also processing your hot JS.

Real-world impact: on certain benchmarks Safari's JSCore beats V8 — especially on compute-heavy, type-stable code, where LLVM's loop, SIMD, and inlining strategies are more aggressive than TurboFan's.

But fast-JS writing is the same trade across engines — the 12 rules apply word-for-word to JSCore.

Optimizing px2rem to 24 ms is roughly the JS ceiling. Beyond that, you have to stop writing JS. That's WebAssembly's slot.

V8 actually runs two parallel pipelines: JS uses the four-tier covered in Ch3 (Ignition→Sparkplug→Maglev→TurboFan); Wasm has its own two-tier — Liftoff (baseline, compiles in milliseconds) and TurboFan (peak, shared backend). Both pipelines share the same machine-code memory, the same GC, the same main thread — so Wasm isn't "another language" so much as another shape of the JS performance curve.

And critically: Wasm isn't "fast just by being Wasm". Poorly-written Wasm (frequent boundary calls, unfriendly memory layout, no vectorization) sometimes loses to equivalent optimized JS.

The last word of this piece, then: push JS to its limit with the 12 rules first; reach for Wasm second. In most business code, JS optimization solves 80% of perf without adding build complexity.

Every "how to see what V8 is doing" tool used across this piece, in one place. Save this chapter as a cheatsheet — next time you face slow JS, copy-paste from here.

Chrome DevTools → Memory → Take heap snapshot, then:

1. Top-left dropdown → "Class filter", search for your constructor (e.g. Object).
2. Expand any entry, you'll see map :: system / Map @0x... — that's the Hidden Class's physical address.
3. Click the Map entry; the Retainers panel below lists every object pointing at the same Hidden Class. Tens of thousands sharing one map ✓ — shapes stable. A few objects each pointing at different maps ✗ — shapes split.

This is the most direct way to verify shape stability — easier than diffing %DebugPrint output.