← all workloads

operator_typecheck

`n` functions, each a long arithmetic expression whose operands alternate among float/int/uint (typed locals and literals of differing kinds). Every `+`/`-`/`*` must resolve the builtin arithmetic operator overload set and insert an implicit conversion to the common type — the "checking the types of 1 and 2 in 1 + 2" cost, multiplied across many nodes. Contrast `parse`, whose same-type float expressions skip overload ranking. Module mode -> the signal is SemanticChecking, not codegen. Scaling null: n scales fixed-length expressions; ideal typecheck cost is O(n).

bucket: typecheck  ·  mode: module  ·  flags: (none)

Phase composition vs N (stacked sub-counters)

compileInner split into phase buckets (named leaves + (self) residuals) stacked across the sweep sizes — the top edge is compileInner, so you can see which phase drives the scaling.

Scaling analysis

floor-subtracted power-law fit (t − floor) = a·Nk; floor = the minimal workload (fixed per-compile cost), k the global exponent, top-2× the local high-end doubling ratio.

Growth attribution (N=200 → N=1600)

compileInner grows by 306 ms across the sweep; the mutually-exclusive phase buckets below partition that growth exactly (no nested-timer double counting). × lin is the same metric as the top-level panels, per bucket: the end point vs a linear expectation anchored to the bucket's share of the minimal floor and fitted on the low-N half — 1.0 = grew exactly linearly, >1 bends up. The super-linearity lives where × lin (and k) are red.

Near-constant (≤2% of growth each): frontEndExecute (self) (0→3 ms), compileInner (self) (0→0 ms).

Sweep numbers (median ms)