Academy — Sanjib Sikder

JavaScript Is Not Interpreted

The mental model most developers carry — "JavaScript is a slow, interpreted scripting language" — has been wrong for fifteen years. Modern engines like V8 (Chrome, Node.js), SpiderMonkey (Firefox), and JavaScriptCore (Safari) compile your code to native machine code at runtime. This is Just-In-Time (JIT) compilation.

The pipeline in V8 looks roughly like this:

Your JS source
    ↓ parse
Abstract Syntax Tree (AST)
    ↓ Ignition (bytecode compiler)
Bytecode — runs immediately, collects profiling data
    ↓ TurboFan (optimising JIT, triggered on "hot" code)
Optimised native machine code — runs at near-C++ speed
    ↓ (if assumptions break)
Deoptimisation — back to bytecode

The engine makes assumptions about your code to optimise it. If those assumptions are violated — wrong type, unexpected shape — the engine throws away the compiled code and starts over. This is called deoptimisation and it is the most common source of unexpected slowness.

Hidden Classes — The Shape of an Object

V8 does not treat objects as hash maps. It assigns each object a hidden class (also called a "shape" or "map") that describes its property layout. Objects with the same hidden class share compiled code. Changing the shape of an object forces V8 to create a new hidden class.

JavaScript

Ctrl+Enter to run

// These two objects look identical but have different hidden classes
// because their properties were added in a different order

function makeStudentA(name, marks) {
const s = {};
s.name = name; // hidden class transition: {} → { name }
s.marks = marks; // hidden class transition: { name } → { name, marks }
return s;
}

function makeStudentB(name, marks) {
const s = {};
s.marks = marks; // { marks }
s.name = name; // { marks, name } — DIFFERENT hidden class to makeStudentA
return s;
}

const a = makeStudentA("Rahul", 82);
const b = makeStudentB("Priya", 91);

// They look the same
console.log(JSON.stringify(a));
console.log(JSON.stringify(b));

// But V8 cannot reuse the same compiled code for both
// because the property layout in memory is different

// The fix: always add properties in the same order, or use object literals
function makeStudentC(name, marks) {
return { name, marks }; // always same shape — one hidden class, fast
}

console.log("\nAll three have same visible structure — but only C is consistently fast");

// These two objects look identical but have different hidden classes
// because their properties were added in a different order

function makeStudentA(name, marks) {
const s = {};
s.name = name; // hidden class transition: {} → { name }
s.marks = marks; // hidden class transition: { name } → { name, marks }
return s;
}

function makeStudentB(name, marks) {
const s = {};
s.marks = marks; // { marks }
s.name = name; // { marks, name } — DIFFERENT hidden class to makeStudentA
return s;
}

const a = makeStudentA("Rahul", 82);
const b = makeStudentB("Priya", 91);

// They look the same
console.log(JSON.stringify(a));
console.log(JSON.stringify(b));

// But V8 cannot reuse the same compiled code for both
// because the property layout in memory is different

// The fix: always add properties in the same order, or use object literals
function makeStudentC(name, marks) {
return { name, marks }; // always same shape — one hidden class, fast
}

console.log("\nAll three have same visible structure — but only C is consistently fast");

This is why initialising all properties in the constructor matters — not just for readability, but for performance. Every class instance created by the same constructor will share one hidden class.

The Cost of Dynamic Property Addition

JavaScript

Ctrl+Enter to run

// Benchmark: pre-shaped vs dynamically grown objects
function timeIt(label, fn, iterations = 500000) {
  const start = Date.now();
  let result = 0;
  for (let i = 0; i < iterations; i++) result += fn(i);
  const ms = Date.now() - start;
  console.log(`${label}: ${ms}ms (result: ${result})`);
}

// Dynamic — adds properties after creation, forces hidden class transitions
function dynamicObj(i) {
const o = {};
o.x = i;
o.y = i _ 2;
o.z = i _ 3;
return o.x + o.y + o.z;
}

// Pre-shaped — literal with all properties at once, one hidden class
function shapedObj(i) {
const o = { x: i, y: i _ 2, z: i _ 3 };
return o.x + o.y + o.z;
}

// Class — constructor always adds in same order, best case
class Point {
constructor(i) {
this.x = i;
this.y = i _ 2;
this.z = i _ 3;
}
}
function classObj(i) {
const o = new Point(i);
return o.x + o.y + o.z;
}

timeIt("dynamic ({}+add)", dynamicObj);
timeIt("literal {x,y,z}", shapedObj);
timeIt("class constructor", classObj);

Run this a few times. The shaped literal and class constructor will consistently beat the dynamic version — sometimes dramatically. The gap widens with more properties and more iterations.

Monomorphic vs Polymorphic Call Sites

An inline cache is V8's mechanism for remembering what type it saw at a particular operation. If a property access always sees the same hidden class, the cache is monomorphic and V8 compiles it to a direct memory offset — essentially a C struct access. If it sees multiple shapes, the cache becomes polymorphic and the engine must do more work each time.

JavaScript

Ctrl+Enter to run

function timeIt(label, fn, iterations = 1000000) {
  const start = Date.now();
  let r = 0;
  for (let i = 0; i < iterations; i++) r += fn(i);
  console.log(`${label}: ${Date.now() - start}ms`);
}

// Monomorphic: getMarks always receives the same hidden class
const students = Array.from({ length: 1000 }, (_, i) => ({ name: "S" + i, marks: i % 100 }));

function getMarks(s) { return s.marks; }

// Warm up with one shape
function monoTest(i) {
return getMarks(students[i % students.length]);
}

// Polymorphic: getMarks receives objects of different shapes
const mixed = [
...Array.from({ length: 500 }, (_, i) => ({ name: "A", marks: i })),
...Array.from({ length: 500 }, (_, i) => ({ marks: i, name: "B" })), // different order!
...Array.from({ length: 500 }, (_, i) => ({ marks: i, name: "C", extra: true })), // extra prop!
];

function polyTest(i) {
return getMarks(mixed[i % mixed.length]);
}

timeIt("monomorphic (1 shape)", monoTest);
timeIt("polymorphic (3 shapes)", polyTest);

The rule: the fewer distinct shapes a function sees at any call site, the faster it runs. This is why mixing objects of different shapes in the same array — even visually similar ones — can silently hurt performance.

Type Consistency — Don't Change Types Mid-Flight

V8 specialises compiled code for the types it has observed. If a variable changes type, the specialised code is thrown away:

JavaScript

Ctrl+Enter to run

function timeIt(label, fn, n = 2000000) {
  const start = Date.now();
  let r = 0;
  for (let i = 0; i < n; i++) r += fn(i);
  console.log(`${label}: ${Date.now() - start}ms (r=${r})`);
}

// Stable types — V8 can specialise for integer arithmetic
function stableTypes(i) {
let x = i; // always number
let y = i * 2; // always number
return x + y;
}

// Unstable types — x starts as number, occasionally becomes string
function unstableTypes(i) {
let x = i;
if (i % 10000 === 0) x = "reset"; // rare but ruins specialisation
let y = i * 2;
return typeof x === "number" ? x + y : y;
}

timeIt("stable types", stableTypes);
timeIt("unstable types", unstableTypes);

A single type change — even happening once every ten thousand iterations — can prevent V8 from ever specialising that function. The engine cannot trust its assumption, so it falls back to generic code for every call.

Arrays: Stay Monomorphic

Arrays in V8 have element kinds — a classification of what type of values they contain. A dense integer array (PACKED_SMI_ELEMENTS) is the fastest possible. As soon as you mix in a float, a hole, or a non-number, the array is reclassified and never promoted back up:

JavaScript

Ctrl+Enter to run

// Element kind ladder (fast → slow):
// PACKED_SMI_ELEMENTS     [1, 2, 3]           — dense integers
// PACKED_DOUBLE_ELEMENTS  [1, 2.5, 3]         — dense floats
// PACKED_ELEMENTS         [1, "a", true]      — dense mixed
// HOLEY_SMI_ELEMENTS      [1, , 3]            — sparse integers
// HOLEY_DOUBLE_ELEMENTS   [1, , 2.5]          — sparse floats
// HOLEY_ELEMENTS          [1, , "a"]          — worst case

function timeIt(label, fn, n = 500000) {
const start = Date.now();
let r = 0;
for (let i = 0; i < n; i++) r += fn(i);
console.log(`${label}: ${Date.now() - start}ms`);
}

// Dense integer array — best case
const smiArr = Array.from({ length: 100 }, (_, i) => i);
function sumSmi(i) {
let s = 0;
for (const x of smiArr) s += x;
return s;
}

// Float array — one downgrade
const floatArr = Array.from({ length: 100 }, (_, i) => i + 0.1);
function sumFloat(i) {
let s = 0;
for (const x of floatArr) s += x;
return s;
}

// Holey array — created with new Array(n) and then filled
const holeyArr = new Array(100);
for (let i = 0; i < 100; i += 2) holeyArr[i] = i; // gaps at odd indices
function sumHoley(i) {
let s = 0;
for (const x of holeyArr) s += (x || 0);
return s;
}

timeIt("packed SMI [0,1,2…]", sumSmi);
timeIt("packed float [0.1…]", sumFloat);
timeIt("holey [0,,2,,4…]", sumHoley);

console.log("\nTip: prefer Array.from() or [] over new Array(n) for dense arrays");

// Element kind ladder (fast → slow):
// PACKED_SMI_ELEMENTS     [1, 2, 3]           — dense integers
// PACKED_DOUBLE_ELEMENTS  [1, 2.5, 3]         — dense floats
// PACKED_ELEMENTS         [1, "a", true]      — dense mixed
// HOLEY_SMI_ELEMENTS      [1, , 3]            — sparse integers
// HOLEY_DOUBLE_ELEMENTS   [1, , 2.5]          — sparse floats
// HOLEY_ELEMENTS          [1, , "a"]          — worst case

function timeIt(label, fn, n = 500000) {
const start = Date.now();
let r = 0;
for (let i = 0; i < n; i++) r += fn(i);
console.log(`${label}: ${Date.now() - start}ms`);
}

// Dense integer array — best case
const smiArr = Array.from({ length: 100 }, (_, i) => i);
function sumSmi(i) {
let s = 0;
for (const x of smiArr) s += x;
return s;
}

// Float array — one downgrade
const floatArr = Array.from({ length: 100 }, (_, i) => i + 0.1);
function sumFloat(i) {
let s = 0;
for (const x of floatArr) s += x;
return s;
}

// Holey array — created with new Array(n) and then filled
const holeyArr = new Array(100);
for (let i = 0; i < 100; i += 2) holeyArr[i] = i; // gaps at odd indices
function sumHoley(i) {
let s = 0;
for (const x of holeyArr) s += (x || 0);
return s;
}

timeIt("packed SMI [0,1,2…]", sumSmi);
timeIt("packed float [0.1…]", sumFloat);
timeIt("holey [0,,2,,4…]", sumHoley);

console.log("\nTip: prefer Array.from() or [] over new Array(n) for dense arrays");

The Cost of arguments and try/catch

Some patterns prevent TurboFan from optimising a function at all. Historically, arguments, try/catch inside hot loops, and eval were full deoptimisation triggers. Modern V8 has improved but these patterns still carry measurable cost:

JavaScript

Ctrl+Enter to run

function timeIt(label, fn, n = 1000000) {
  const start = Date.now();
  let r = 0;
  for (let i = 0; i < n; i++) r += fn(i, i + 1, i + 2);
  console.log(`${label}: ${Date.now() - start}ms`);
}

// Clean — named params, no special objects
function cleanSum(a, b, c) {
return a + b + c;
}

// Using arguments object — inhibits some optimisations
function argumentsSum() {
let s = 0;
for (let i = 0; i < arguments.length; i++) s += arguments[i];
return s;
}

// Rest params — modern alternative to arguments, better optimised
function restSum(...args) {
return args[0] + args[1] + args[2];
}

timeIt("named params (a,b,c)", cleanSum);
timeIt("arguments object ", argumentsSum);
timeIt("rest params ...args", restSum);

Rest parameters (...args) are the modern replacement for arguments. They are a real array, they are better optimised, and they compose cleanly with destructuring and spread.

Practical Rules

Everything above distils into a short list of habits:

JavaScript

Ctrl+Enter to run

// Rule 1: Initialise all object properties in the constructor / literal
// SLOW — shape transitions
function bad1() {
  const o = {};
  o.x = 1; o.y = 2; // two transitions
  return o;
}
// FAST — one shape from birth
function good1() { return { x: 1, y: 2 }; }

// Rule 2: Don't change variable types
function good2(arr) {
let sum = 0; // always number
for (const x of arr) sum += x;
return sum;
}

// Rule 3: Keep arrays dense and uniform
const dense = [1, 2, 3, 4, 5]; // PACKED_SMI — fast
// const holey = [1, , 3]; // HOLEY — avoid
// const mixed = [1, "two", true]; // PACKED_ELEMENTS — slower

// Rule 4: Prefer for...of over for...in on arrays
function sumOf(arr) {
let s = 0;
for (const x of arr) s += x; // engine can optimise iteration
return s;
}

// Rule 5: Keep functions small — large functions are harder to JIT
// Rule 6: Avoid delete — it turns the object into a "slow" hash map mode
const obj = { a: 1, b: 2, c: 3 };
// delete obj.b; // degrades obj to dictionary mode — avoid in hot paths
// obj.b = undefined; // preferred — keeps the shape intact

console.log(good1());
console.log(good2(dense));
console.log(sumOf(dense));
console.log("Rules demonstrated — check timing with timeIt() wrappers in real code");

// Rule 1: Initialise all object properties in the constructor / literal
// SLOW — shape transitions
function bad1() {
  const o = {};
  o.x = 1; o.y = 2; // two transitions
  return o;
}
// FAST — one shape from birth
function good1() { return { x: 1, y: 2 }; }

// Rule 2: Don't change variable types
function good2(arr) {
let sum = 0; // always number
for (const x of arr) sum += x;
return sum;
}

// Rule 3: Keep arrays dense and uniform
const dense = [1, 2, 3, 4, 5]; // PACKED_SMI — fast
// const holey = [1, , 3]; // HOLEY — avoid
// const mixed = [1, "two", true]; // PACKED_ELEMENTS — slower

// Rule 4: Prefer for...of over for...in on arrays
function sumOf(arr) {
let s = 0;
for (const x of arr) s += x; // engine can optimise iteration
return s;
}

// Rule 5: Keep functions small — large functions are harder to JIT
// Rule 6: Avoid delete — it turns the object into a "slow" hash map mode
const obj = { a: 1, b: 2, c: 3 };
// delete obj.b; // degrades obj to dictionary mode — avoid in hot paths
// obj.b = undefined; // preferred — keeps the shape intact

console.log(good1());
console.log(good2(dense));
console.log(sumOf(dense));
console.log("Rules demonstrated — check timing with timeIt() wrappers in real code");

Measuring: The Only Truth

Rules and intuitions are starting points. The only way to know what is actually slow in your code is to measure it. In a browser, use performance.now() for microsecond precision. In Node.js, use process.hrtime.bigint(). In production, use a profiler (Chrome DevTools Performance tab, --prof flag in Node).

JavaScript

Ctrl+Enter to run

// performance.now() is available in the sandbox
function bench(label, fn, iterations = 1000000) {
  // Warmup — let V8 JIT compile the function
  for (let i = 0; i < 1000; i++) fn(i);

const start = performance.now();
let result = 0;
for (let i = 0; i < iterations; i++) result = fn(i);
const end = performance.now();

const ms = (end - start).toFixed(2);
const ns = ((end - start) * 1e6 / iterations).toFixed(1);
console.log(`${label.padEnd(28)} ${ms.padStart(8)}ms (${ns} ns/op)`);
return result;
}

// Compare two implementations of the same thing
function sumForOf(n) {
const arr = [1, 2, 3, 4, 5];
let s = 0;
for (const x of arr) s += x;
return s + n * 0;
}

function sumWhile(n) {
const arr = [1, 2, 3, 4, 5];
let s = 0, i = 0;
while (i < arr.length) s += arr[i++];
return s + n * 0;
}

function sumReduce(n) {
return [1, 2, 3, 4, 5].reduce((a, b) => a + b, 0) + n * 0;
}

console.log("Warmup done. Running benchmarks…\n");
bench("for...of loop", sumForOf);
bench("while loop", sumWhile);
bench("Array.reduce", sumReduce);

// performance.now() is available in the sandbox
function bench(label, fn, iterations = 1000000) {
  // Warmup — let V8 JIT compile the function
  for (let i = 0; i < 1000; i++) fn(i);

const start = performance.now();
let result = 0;
for (let i = 0; i < iterations; i++) result = fn(i);
const end = performance.now();

const ms = (end - start).toFixed(2);
const ns = ((end - start) * 1e6 / iterations).toFixed(1);
console.log(`${label.padEnd(28)} ${ms.padStart(8)}ms (${ns} ns/op)`);
return result;
}

// Compare two implementations of the same thing
function sumForOf(n) {
const arr = [1, 2, 3, 4, 5];
let s = 0;
for (const x of arr) s += x;
return s + n * 0;
}

function sumWhile(n) {
const arr = [1, 2, 3, 4, 5];
let s = 0, i = 0;
while (i < arr.length) s += arr[i++];
return s + n * 0;
}

function sumReduce(n) {
return [1, 2, 3, 4, 5].reduce((a, b) => a + b, 0) + n * 0;
}

console.log("Warmup done. Running benchmarks…\n");
bench("for...of loop", sumForOf);
bench("while loop", sumWhile);
bench("Array.reduce", sumReduce);

Always warm up before measuring — V8 needs several hundred calls before TurboFan kicks in. Cold measurements tell you about bytecode performance, not JIT performance, which is rarely what you care about.

What You Have Learned

Writing fast JavaScript is not about avoiding the language — it is about writing code that lets the engine do its job.

The key ideas:

V8 compiles hot code to native machine code via TurboFan — this is why JS can be fast
Hidden classes describe object shape; keeping shapes consistent lets V8 share compiled code across all objects of that shape
Inline caches remember the type seen at each operation; monomorphic (one type) = fast, polymorphic (many types) = slower
Changing variable types mid-function forces deoptimisation — the compiled code is discarded
Arrays have element kinds (PACKED_SMI → PACKED_DOUBLE → HOLEY) — once downgraded, never promoted back
delete turns objects into slow dictionary mode in hot paths — prefer obj.prop = undefined
arguments is less optimised than rest parameters
Measure first — performance.now() with warmup; intuitions without measurement are guesses

In the next lesson: Memory Management & Garbage Collection — how V8 decides what to keep and what to collect, what causes memory leaks in long-running applications, and how to find and fix them.

Performance & the JavaScript Engine

JavaScript Is Not Interpreted

Hidden Classes — The Shape of an Object

The Cost of Dynamic Property Addition

Monomorphic vs Polymorphic Call Sites

Type Consistency — Don't Change Types Mid-Flight

Arrays: Stay Monomorphic

The Cost of arguments and try/catch

Practical Rules

Measuring: The Only Truth

What You Have Learned