Graph Capture

A compiler cannot optimise what it cannot see. Eager frameworks execute one operation at a time with ordinary control flow in between, so the first job is recovering a graph of what the program does — by tracing an execution, or by rewriting the bytecode as it runs. Everything downstream depends on how much of the program this step captures.

Tracing loses anything that depends on the data, because a trace records the branch that happened rather than the branch that exists. Bytecode-level capture handles more and falls back to eager execution at the parts it cannot express, which produces graph breaks — and a model with a break in its inner loop gets almost none of the benefit. Counting and removing breaks is usually the first real work of making a model compile well.

The captured region is a straight-line dataflow graph; every data-dependent branch splits it. Speedup comes from fusion and scheduling across the graph, so it scales with the size of the largest unbroken region rather than with the total number of operations — which is why one break in a hot loop can cost most of the gain.