Ask HN: How can I learn about performance optimization?
Performance optimization emerges here as a broad, experience-driven skill that depends heavily on context: are you tuning a game engine, a cloud service, a database, or embedded code on a tiny microcontroller? Contributors emphasize learning to measure and profile correctly, understanding system architecture and bottlenecks (from algorithms and data structures down to CPU caches and GPUs), and prioritizing high‑level problem and algorithm choices before micro-optimizations. They share a large set of books, courses, and talks, while repeatedly warning against both premature optimization and the opposite failure: shipping obviously inefficient code and assuming performance can be fixed later.
Scope of “Performance Optimization”
- Commenters stress that “performance” is highly context- and domain-specific (games vs web vs databases vs HFT vs embedded vs cloud systems).
- Clarifying what you’re optimizing (latency vs throughput vs memory vs energy vs code size vs UX) is seen as essential.
- Several replies ask what stack the asker is on; without that, advice is necessarily generic.
Core Methodology: Measure, Don’t Guess
- Strong consensus: always measure first, then optimize.
- Emphasis on:
- Profiling to find real hotspots instead of guessing.
- Building reproducible benchmarks with real workloads.
- Layered view: measurement → modeling (queues, Little’s Law) → instrumentation.
- Observability and tooling (profilers, tracing, OS tools, browser dev tools) are called the practical entry point.
What to Optimize First
- Common heuristics:
- Do less work: better algorithms, fewer allocations, avoid redundant I/O, pull work out of loops.
- Avoid remote/network/DB calls in tight loops; batch work when possible.
- Focus on “hot paths”; infrequent paths can be slower unless they’re safety-critical.
- Data locality and simple linear data structures (arrays/vectors) are heavily emphasized.
- A layered view recurs: 1) the problem definition, 2) algorithm choice, 3) micro-optimizations. Biggest wins usually come from the top.
System & Hardware Understanding
- Many recommend learning modern CPU and memory hierarchies, caches, branch prediction, and micro-architectural analysis.
- Queueing theory and simple back-of-the-envelope models are suggested for system-level performance.
- Some note that GPU and real-time audio/game optimization are “different universes” with strict time budgets.
Resources & Learning Paths
- Frequent recommendations:
- University-style courses on performance engineering and optimization.
- Books on systems performance, software dynamics, efficient programs, and “every computer performance” style overviews.
- Blogs and manuals focused on systems performance, CPU optimization, and language-specific performance guides.
- Talks and courses on data-oriented design, low-level optimization, and challenge writeups (e.g., “billion row” competitions).
Experience, Organization, and Culture
- Several say performance skill is best developed by repeatedly optimizing real systems, ideally with mentorship.
- Advice to understand company architecture, ownership, SLAs, and roadmaps so you don’t hyper-optimize soon-to-be-deprecated components.
- Discussion around a famous “boot-time” anecdote raises both admiration for ambitious goals and concern about toxic pressure and misplaced optimization.
Cautions and Disagreements
- Repeated reminders not to misuse the “premature optimization” quote; it warns against unnecessary complexity, not against caring about performance.
- Some resources (e.g., older manuals) are described as valuable but partially outdated; “trust but verify” is recommended.
- Debate around tradeoffs between focusing only on the critical 3% vs the cumulative cost of many “small” inefficiencies.