Clean code! Horrible performance?
summary
Claim: clean code is rarely the root cause of catastrophic slowdown; the hard numbers and fixes matter. Cites Amdahl's law, examples where redundant startup/cleanup calls cause leaks, and a case of 15× traffic growth solved by operability work, network tuning and consolidating external requests rather than low‑level tricks. Notes business effects (Amazon: every 100 ms ≈ 1% sales loss; Google: 500 ms ≈ 20% traffic drop) and prescribes measuring hot paths, using batching external calls, and optimizing only proven bottlenecks.
AI-written summary · about
chapters (30)
- 0:00Introduction
- 1:30Clean code and performance matter
- 2:35Defining clean code and quality
- 8:40High-quality software importance
- 10:08Software quality definitions
- 12:17Four pillars of quality
- 14:41Clean code improves quality
- 16:05Why C++ is widely used
- 19:16C++ evolution and economics
- 20:42Defining software performance
- 22:08Aspects of software performance
- 24:41Runtime performance explained
- 27:22Measuring runtime performance
- 29:10Other performance types
- 30:34Is clean code slower
- 32:19Clean code for maintainability
- 33:07Optimization trade-offs
- 36:04Performance vs clean code
- 37:29Performance cost examples
- 39:40Premature optimization fails
- 40:00Performance vs operability lesson
- 44:11Scaling without code optimization
- 45:16Operability and resource use
- 46:45Batching and caching
- 47:49Costly language features
- 49:33Optimize only hot path
- 50:14When to stop optimizing
- 51:42Good enough performance
- 52:26Hardware vs developer cost
- 54:18Clean code and performance
