← all workloads

generic_nesting_eval

The generic_nesting chain with a method REQUIRED by the constraint interface and called recursively through the witnesses (`first.eval() + second.eval()`), so overload resolution and inheritance-witness lookup run at every nesting level instead of only type checking the aliases. Same depth axis as generic_nesting, much steeper constant: measured ~2.9x per level when added (2026-07), vs ~3-4x per level from substitution alone but starting an order of magnitude higher at equal depth. Scaling null: each level adds O(1) declarations and one call site, so ideal front-end cost is O(n). The ladder tops out below generic_nesting's because the per-level multiplier bites sooner.

bucket: sema  ·  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=8 → N=14)

compileInner grows by 46 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): SemanticChecking (8→8 ms), generateOutput (self) (1→1 ms), parseTranslationUnit (0→0 ms), frontEndExecute (self) (0→0 ms), compileInner (self) (0→0 ms).

Sweep numbers (median ms)