44. Inheritance, and measuring the tree-walker

A dog is an animal

class Animal {
  init(name) { this.name = name; }
  speak() {
    print this.name + " makes a sound";
  }
}

class Dog < Animal {
  speak() {
    super.speak();
    print this.name + " barks";
  }
}

Dog("Rex").speak();
// Rex makes a sound
// Rex barks

Dog has no init, yet Dog("Rex") sets name. And Dog’s speak replaces Animal’s, but can still call it.

Inheritance: one more place to look

class Dog < Animal stores Animal as Dog’s superclass. Finding a method then becomes a walk up that chain:

findMethod(name: string) {
  return this.methods.get(name)
    ?? this.superclass?.findMethod(name);
}

That’s all inheritance needs. Dog("Rex") finds init in Animal and binds it to the new Dog instance.

The superclass is an ordinary expression, evaluated when the class statement runs, so it has to hold a class: let A = "x"; class B < A {} fails at runtime with Superclass must be a class. One mistake is caught earlier: class A < A {} is a resolver error, A class can't inherit from itself.

super: decided where it’s written

super.speak() means “the speak above the class this method was written in”, called on the same this. A tempting shortcut is to take this’s class and ask for its superclass. It breaks with three levels:

class A { m() { print "A.m"; } }
class B < A {
  m() { print "B.m"; super.m(); }
}
class C < B {}
C().m();

Running C().m() reaches B.m with this a C instance. “The superclass of this’s class” is B, so super.m() would call B.m again, which would call B.m again, until the stack overflows. The right answer, A, depends on where the method was written. That’s lexical scope again, so the interpreter uses the same trick it used for this: an environment. When a class with a superclass is declared, it wraps the methods in one holding super:

if (sup) {
  this.env = new Environment(this.env);
  this.env.define('super', sup);
}
// ...methods capture this.env...
if (sup) this.env = this.env.enclosing!;

The resolver adds a matching scope, so super gets a distance like any variable, and this is always exactly one environment closer:

case 'super': {
  const d = this.locals.get(e)!;
  const sup = this.env.getAt(d, 'super');
  const me = this.env.getAt(d - 1, 'this');
  const m = sup.findMethod(e.method.lexeme);
  if (!m) throw new RuntimeError(/*...*/);
  return m.bind(me);
}

class A {
  m() { print "A.m"; }
}
class B < A {
  m() {
    print "B.m";
    super.m();
  }
}
class C < B {}
C().m();

class Animal {
  init(name) { this.name = name; }
  speak() {
    print this.name + " makes a sound";
  }
  hello() { print "I am " + this.name; }
}

class Dog < Animal {
  speak() {
    super.speak();
    print this.name + " barks";
  }
}

let d = Dog("Rex");
d.hello();
d.speak();

Measuring the tree-walker

Drip is finished. How fast is it? The companion code has a second Drip implementation, the bytecode VM you’ll build in Part IV, and a harness that runs both on the benchmark programs in corpus/benchmark/ (adapted, like the whole test corpus, from Crafting Interpreters^[1]). fib computes fib(35) recursively; zoo and method_call call methods in loops.

The harness starts a fresh Node process for each program and engine, and times the whole run(src): scanning, parsing, resolving and running. These numbers are from this book’s benchmark run, in companion/ts/results/drip-bench-2026-10-31.md: Node 22.23.4 on a shared cloud VM, and the file records one run per program. By chapter 24’s standards, that’s a first look, not a verdict.

Read it carefully:

• Most programs run several times faster on the VM. The biggest wins are on programs full of calls, fields and methods.
• zoo_batch isn’t a speed measurement. It loops until 10 seconds of clock time have passed, then prints how many batches it finished. Both engines take about 10 seconds by design. The useful number is the batch count, and the results file doesn’t record it.
• string_equality has no VM time. The VM refused to compile it: its bytecode allows at most 256 constants per chunk, and this program has more. A limit, not a slowness.
• instantiation and equality came out slower on the VM. A faster design isn’t faster at everything, and one run on a shared machine can’t tell you why. Part IV looks closer.

Why walking a tree is slow

Take one tiny piece of fib: n - 2. The CPU can subtract in a single instruction. Here’s what the tree-walker does:

evaluate(binary)           switch on kind
  evaluate(variable n)     switch on kind
    lookUp: locals.get(node)    Map lookup
    getAt(0): ancestor loop
    values.get("n")             Map lookup
  evaluate(literal 2)      switch on kind
  nums(...)                type checks
  subtract                 the real work

Three recursive calls, three dispatches on kind, two hash-map lookups and two type checks, for one subtraction. That surrounding bookkeeping is the interpreter’s overhead, and there are three big sources of it.

Dispatch on every node. Each node costs a call and a switch to find out what it is, every time it runs, though the answer never changes.

Pointer-chasing. The tree is a web of separate objects joined by references, and so is the environment chain. Each step loads the next pointer, and the step after can’t start until that load arrives. That’s chapter 20’s pointer-chasing: dependent loads are far slower than walking an array in order^[2].

Environments made of Maps. Every variable read is at least one hash lookup, by name (globals take two, has then get). Map lookups are fast for a general table^[3], but nothing like reading a value at a known position. And every call allocates a new Environment with a new Map, every method read allocates a bound function plus another environment, and every return throws an object to unwind the host stack.

Your turn

class Shape {
  init(name) { this.name = name; }
  show() {
    print this.name;
    print this.area();
  }
}

class Square < Shape {
  init(side) {
    this.side = side;
  }
  area() {
    return this.side * this.side;
  }
}
Square(3).show();

function evaluate(node, stats) {
  if (node.kind === 'num') {
    return node.value;
  }
  const l = evaluate(node.left, stats);
  const r = evaluate(node.right, stats);
  if (node.kind === 'add') return l + r;
  return l * r;
}

What you learned

• Inheritance: class B < A makes A the superclass, and findMethod walks up the chain. A subclass overrides by reusing a name.
• super is decided by where a method is written. Drip keeps the superclass in an environment made at class declaration, so super is found by scope depth, and this is one environment closer.
• The VM beat the tree-walker on most benchmark programs, in one run on one machine. zoo_batch runs for a fixed time, so its time says nothing about speed.
• Interpreter overhead: node dispatch, pointer-chasing through the tree and environments, and Map-based environments that allocate on every call.

That’s Drip: a whole language, about a thousand lines of TypeScript. Next, Part IV rebuilds it as a compiler and a virtual machine, and removes that overhead one piece at a time.