perf-loop

Guides iterative performance optimization with stable benchmarks and correctness gates.

4.4k|154|Updated Mar 17, 2026
One-click install
npx skills add https://github.com/fallow-rs/fallow --skill perf-loop
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: perf-loop
Source: https://github.com/fallow-rs/fallow/tree/main/.agents/skills/perf-loop
Command: npx skills add https://github.com/fallow-rs/fallow --skill perf-loop

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Performance work often fails because benchmarks are unstable, baselines are missing, or optimizations are kept without reproducible evidence. This Skill enforces a disciplined loop so every optimization is measured, verified, and regression-free.

Core Features & Use Cases

  • Stable Benchmark Discipline: Preserves benchmark identity and workload so before-and-after comparisons stay valid, and requires a new benchmark identifier for materially different workloads.
  • Evidence-Based Optimization: Requires profiling the hot path before editing, recording a statistically useful baseline, and re-running correctness checks after each bounded change.
  • Regression Gating: Keeps a change only when the improvement is reproducible and no contract regresses, and forbids reporting gains from debug builds or incomparable fixtures.
  • Use Case: While optimizing the Fallow analyzer, you profile the hot path, implement one bounded change, re-run the same benchmark and correctness checks, and only merge when the gain reproduces.

Quick Start

Use the perf-loop skill to guide my next performance optimization on this codebase with a stable benchmark and correctness checks.

Frequently Asked Questions about perf-loop

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I optimize code performance without regressions?

Follow a measured loop: pick a stable benchmark, record a baseline, profile the hot path, make one bounded change, then re-run the same benchmark and correctness checks. Keep the change only if the improvement reproduces and no contract regresses.

How to benchmark before and after a code change?

Preserve the benchmark's identity and workload, record a statistically useful baseline before editing, and re-run the identical benchmark after the change. Use a new benchmark identifier only when the workload materially changes.

Why are my performance gains not reproducible?

Gains often vanish when measured from debug builds or incomparable fixtures. Always measure optimized builds against the same workload, and discard results that cannot be reproduced across runs.

When should I create a new benchmark instead of reusing one?

Create a new benchmark identifier when the workload changes materially, since comparing against the old baseline would be invalid. Keeping benchmark identity stable is what makes before-and-after evidence meaningful.

What are the limitations of benchmark-driven optimization?

Benchmark results only reflect the measured workload and environment, so they can miss real-world variance. This loop mitigates that by requiring profiling first, correctness checks, and a final review step before accepting changes.