Performance Baselines

The same baseline-pinning pattern used for comparing weights (see Comparison Editor) applies to comparing performance: pin a known-good runtime trace as the baseline, and compare a new trace against it, rather than trying to judge a single trace's numbers in isolation.

Why a baseline matters more for performance than for weights

A weight diff has a natural zero point - unchanged is unchanged, regardless of context. A performance number rarely does: whether "340ms per step" is good or bad depends entirely on what it's being compared to. Pinning a baseline trace turns "is this fast" into the much more answerable "is this faster or slower than the last known-good run, and where specifically did the difference come from."

What gets compared

With a baseline and a candidate trace both loaded, comparison is available at the same granularities as everywhere else in Tensormorph:

• Whole-run - total wall-clock time, and where estimable, FLOP throughput.
• Per-layer - a Layer Profile of per-layer timing, baseline against candidate, immediately showing which specific layer regressed rather than only that the total got slower.
• Per-step, over training - for a captured sequence of steps rather than a single one, whether a regression is consistent or intermittent.

Regression as a Problems-panel entry

A performance baseline comparison configured with a threshold (candidate slower than baseline by more than X%) can raise a flagged entry in the Problems panel the same way a statistical outlier does - making a performance regression something CI Validation can gate on, not just something a human notices by eye.

Related resources

• Runtime Traces - capturing the traces a performance baseline compares.
• FLOPs - a structural, estimate-based complement to a measured baseline comparison.
• CI Validation - gating a pipeline on a performance regression.