Laws of Performant Software

Crista’s Five Laws of Performant Software are a checklist from Crista Videira Lopes (2016) for reasoning about program performance before and during optimization.

Why a checklist?

Performance work is easy to misdirect. The laws point at the failure modes that trip people up: picking the wrong battle (language), ignoring small wins, unbounded resources, guessing instead of measuring, and throwing hardware at bad code.

1. Programming language ≪ programmer awareness of performance, no language is magic, any mainstream language can be written fast or slow
2. Small details matter, formalized as $d(f^{\tau }(x),f^{\tau }(y))>e^{\alpha \tau }d(x,y)$, the butterfly effect, where:
   • $x,y$ are two code versions
   • $f^{\tau }$ is running the code for time $\tau$
   • small code differences produce exponentially larger performance differences
3. corr(performance degradation, unbounded resource usage) > 0.9, uncapped threads, caches, and queues eventually exhaust a resource and stall
4. Performance improvements = log(controlled experiments), don’t guess, measure
5. N × bad ≠ good, no amount of cores or RAM rescues poorly-written code

Law 3 in practice

If your program starts threads, use a thread pool with a fixed size. If it reads input, don’t read entire unbounded lines. Every resource needs a ceiling and a defined overflow behaviour (reject, queue with limit, shed load)

Related

• Scalability
• Amdahl’s Law