Flat AST

A data-oriented way to hold a compiler’s abstract syntax tree: instead of a tree of individually heap-allocated nodes linked by pointers, the nodes live in flat contiguous arrays and reference each other by integer index. It’s the abstract-syntax-tree case of struct-of-arrays / data-oriented design — trade pointer-chasing and per-node allocation for dense, cache-friendly arrays.

Why it saves memory

A pointer-linked AST pays for every node: an allocation, a header, padding, and 64-bit pointers for each child edge, scattered across the heap. A flat AST collapses that overhead — nodes pack tightly into arrays, child links shrink to small indices, and allocation becomes a handful of growing buffers instead of millions of tiny objects. The reported result for the V compiler was self-hosting RAM dropping ~6 GB → 400 MB (15×), the flat layout plus other memory work (v-flat-ast). Indices also tend to be more compact than pointers and survive buffer relocation, which helps serialization and incremental rebuilds.

Where it sits in the spoke

It’s a compiler-internals technique — the same axis as typescript-7-go-compiler, but a different lever. TypeScript 7 bought ~10× speed by changing the compiler’s host language (TS→Go); V’s flat AST buys ~15× memory by changing the compiler’s data representation. So the spoke’s compiler-performance story now has two distinct moves: rewrite the language the compiler runs in, or rewrite the shape of the data it builds in memory. The flat/data-oriented idea also rhymes with yaff‘s zero-copy flat-buffer layout (dense contiguous bytes, offsets instead of pointers) — the same memory-layout discipline applied to serialization rather than to an AST.

Its control-flow sibling is monomorphization: flat-AST removes pointer-chasing, monomorphization removes type-dispatch — two halves of the same data-oriented discipline, one applied to memory layout, the other to the code that walks it.

Related

v-flat-ast · typescript-7-go-compiler · yaff · monomorphization · developer-tooling