Premature optimization is famous for being evil, yet many developers obsess over micro-optimizations while ignoring architectural inefficiencies. Effective optimization requires discipline: measure first, identify bottlenecks, then optimize the things that matter.

Establish baselines before optimizing. What is current performance? How is it measured? Latency has distribution—average, 95th percentile, and max differ. Throughput under what load? Without baselines, you cannot measure improvement. Benchmarking tools establish reproducible measurements enabling before-after comparison.

Profile code to identify actual bottlenecks. Human intuition about performance is notoriously poor. A function you assume is slow might be fast. A function you assume is fast might dominate execution time. CPU profilers show where time is spent. Memory profilers identify memory usage patterns. Distributed tracing shows service call patterns.

Amdahl's Law quantifies the returns from optimization. If a program spends 95% of time in one function and 5% elsewhere, optimizing the other 95% by 100x improves total execution time by only 5%. The lesson: optimize the slowest components first. Each optimization has diminishing returns.

Architectural optimization often matters more than code-level optimization. A slow database query dominates requests; optimizing algorithm logic won't help. Adding caches prevents queries entirely. Horizontal scaling handles load better than processor optimization. The right architecture beats clever code.

Measuring matters. Develop benchmark suites that represent realistic workloads. Microbenchmarks are brittle—JIT compilation, garbage collection, and hardware variations create noise. System-level benchmarks using realistic data and concurrency are more meaningful. Continuous benchmarking tracks regressions.

Caching is often the best optimization. Computation is slow; cached results are fast. HTTP caching eliminates requests. Database query result caching eliminates computation. In-memory caches (Redis) replace slow persistent storage. The cost is freshness—how stale can cached data be?

Technical debt accumulates. Early performance optimization might make code harder to maintain. The better approach: write correct, maintainable code first. Profile to identify real problems. Optimize judiciously where it matters. This balances performance with maintainability. The systems that endure are those balancing multiple concerns—correctness, maintainability, and performance—rather than optimizing one ruthlessly at the expense of others.