← ClaudeAtlas

knuths-optimization-principlelisted

Apply Knuth's Optimization Principle when someone wants to optimize code before establishing it's a bottleneck, is using complex data structures for perceived performance, is making code harder to read "for speed", or is debating whether to optimize something that hasn't been profiled. Trigger on phrases like "I should make this faster", "let's pre-optimize this", "I used X instead of Y for performance", "this might be slow", or any discussion where performance is the motivation for added complexity that hasn't been validated by measurement.
The-Artificer-of-Ciphers-LLC/skills-from-the-artificer · ★ 2 · AI & Automation · score 73
Install: claude install-skill The-Artificer-of-Ciphers-LLC/skills-from-the-artificer
# Knuth's Optimization Principle > "Premature optimization is the root of all evil." > — Donald Knuth, 1974 (often attributed; the full quote is more nuanced) ## The core idea Optimizing code before you know it's a bottleneck is one of the most common and costly mistakes in software development. It makes code harder to read, harder to change, and harder to debug — all in service of a performance problem that may not exist, or that may not be in the place you're optimizing. ## The full Knuth quote The complete passage is important and often missed: > "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%." The principle is **not** "never optimize." It's: - Don't optimize before you've measured. - Don't optimize the 97% that doesn't matter. - Do optimize the 3% that actually is the bottleneck — carefully and deliberately. ## Why premature optimization is harmful **It optimizes the wrong things.** Human intuition about where code is slow is notoriously unreliable. Profilers routinely reveal that the bottleneck is somewhere nobody expected. Optimizing your hunch is usually wasted effort. **It adds complexity without benefit.** Optimization techniques — caching, pooling, bitwise tricks, manual memory management, loop unrolling — make code harder to read, maintain, and debug. If there's no performance problem to justify them, you've paid the cost