Software-performance aphorism
Wirth's Law
Software can become slower and more resource-hungry faster than hardware becomes faster, erasing gains users expected from improved machines.
experienced performance depends on hardware capacity / software demand
This is not a physical law or fixed growth rate. New software may perform more work, improve safety, or support broader platforms, so comparisons need a defined workload.
A fixed user task races on two generations while instrumentation separates useful work, abstraction overhead, and background demand.
(%)
The animation runs automatically, pauses on the conclusion, and then repeats. The main control changes the scenario rather than scrubbing the timeline.
- CHANGE
- Software demand growth
- WATCH
- effective speed
- MEANING
- A fixed user task races on two generations while instrumentation separates useful work, abstraction overhead, and background demand.
Faster hardware does not guarantee a faster experience.
Two progress lanes compare hardware throughput with the expanding work required to complete the same defined task.
What it actually says
The aphorism draws attention to system-level performance: hardware capacity, algorithms, dependencies, user-interface layers, data volume, and background services all shape elapsed time.
A fair test freezes the user goal and reports latency, energy, memory, and capability. Raw binary size or one microbenchmark cannot establish the whole claim.
"A useful law compresses a pattern. It does not erase the conditions that make the pattern true."
How the idea developed
The modern form emerged through observation, argument, and later refinement. The timeline separates the first insight from the version now used in textbooks and practice.[1]
Niklaus Wirth publishes A Plea for Lean Software.
Web and mobile stacks make end-to-end performance more visible.
Performance budgets and core web vitals operationalize user-centered constraints.
How the pattern works
The relation becomes useful only when its mechanism, measurement process, and operating range are visible.
More code paths and background work consume capacity.
Generality adds layers and indirection.
Higher fidelity and larger datasets increase work.
This is not a physical law or fixed growth rate. New software may perform more work, improve safety, or support broader platforms, so comparisons need a defined workload.
Where it earns its keep
Applications are strongest when the law changes a decision, measurement, model, or experiment rather than merely providing an analogy.
Set a performance budget
ApplicationTie latency and memory to a defined user task.
Test on representative hardware.
Price capability honestly
ApplicationSome overhead buys security, accessibility, or functionality.
Show the trade-off.
Where it stops working
Hardware and software coevolve, workloads change, and algorithmic improvements can dominate both trends.
"Every update is bloat"
Better: Capability, safety, and platform coverage may have changed."Low-level code is always faster overall"
Better: Architecture, algorithms, and I/O often dominate.Sources and further reading
Original publications and serious secondary scholarship are prioritized over summaries.
- Wirth - A Plea for Lean SoftwarePrimary 1995 essay.https://doi.org/10.1109/2.348001
- ACM Queue - Performance MattersEnd-to-end software performance perspective.https://queue.acm.org/detail.cfm?id=1563874
- web.dev - Performance Budgets 101Operational performance-budget guidance.https://web.dev/articles/performance-budgets-101