23  Spell of Performance Tuning

24 Spell of Performance Tuning

Working seal: spell://performance-tuning/75981D9E3F

Use when: Use when latency or throughput needs disciplined measurement before optimization.

24.1 Copyable Template

Raw template: prompts/spells/performance-tuning.txt

ROLE:
Act as a performance engineer.

OBJECTIVE:
Identify the most likely causes of latency or throughput loss in the supplied code or system description and propose optimizations ranked by expected benefit versus risk.

CONTEXT:
The service has a strict latency budget and runs on commodity cloud hardware. A profiler or benchmark may or may not be available.

CONSTRAINTS:
Do not recommend micro-optimizations before addressing algorithmic or I/O-bound issues.

Separate CPU, memory, allocation, database, and network effects. Mention measurement strategy.

PROCEDURE:
First classify the probable bottleneck class. Then propose measurement steps. After that, list optimization candidates in descending order of expected value.

Note when an optimization trades readability, portability, or safety for speed.

OUTPUT CONTRACT:
Return:

1\. bottleneck hypotheses,

2\. what to measure,

3\. optimization options ranked by expected payoff,

4\. benchmark plan,

5\. rollback criteria.

VERIFICATION:
State how success will be measured and what regression risks need to be watched.

FAILURE BEHAVIOR:
If evidence is insufficient, say what profile, trace, or benchmark data would most improve the recommendation.

24.2 Related Runes

• 1146 benchmark - A performance claim forced to meet measurement. Benchmarks are where speed rhetoric either cashes out or dies.
• 0825 latency - The delay before useful work reaches the caller. Latency is what users feel even when throughput graphs look flattering.
• 1281 throughput - How much useful work the system can push through a narrow world in bounded time.
• 0778 backpressure - Resistance pushed upstream when demand outruns capacity. Without it, overload spreads faster than truth.
• 0615 cache {Run} - Keep likely things close so future cost falls.

24.3 Related Pages

• Canonical Spell Skeleton
• Cast Levels
• Failure Modes
• Canon Map
• Proof by Difference Case
• Recorded Evaluations

24.4 Source Form

24.5 Spell of Performance Tuning

ROLE:

Act as a performance engineer.

OBJECTIVE:

Identify the most likely causes of latency or throughput loss in the supplied code or system description and propose optimizations ranked by expected benefit versus risk.

CONTEXT:

The service has a strict latency budget and runs on commodity cloud hardware. A profiler or benchmark may or may not be available.

CONSTRAINTS:

Do not recommend micro-optimizations before addressing algorithmic or I/O-bound issues.

Separate CPU, memory, allocation, database, and network effects. Mention measurement strategy.

PROCEDURE:

First classify the probable bottleneck class. Then propose measurement steps. After that, list optimization candidates in descending order of expected value.

Note when an optimization trades readability, portability, or safety for speed.

OUTPUT CONTRACT:

Return:

1. bottleneck hypotheses,

2. what to measure,

3. optimization options ranked by expected payoff,

4. benchmark plan,

5. rollback criteria.

VERIFICATION:

State how success will be measured and what regression risks need to be watched.

FAILURE BEHAVIOR:

If evidence is insufficient, say what profile, trace, or benchmark data would most improve the recommendation.