Jon Chery
40 lines
1.1 KiB
Markdown
40 lines
1.1 KiB
Markdown
# Performance — First Principles
|
|
|
|
## 1. The Principles
|
|
|
|
### P1. Measure First
|
|
No optimization without measurement. Intuition about performance is
|
|
usually wrong.
|
|
|
|
### P2. Critical Path Focus
|
|
Optimize what users actually wait for. The 95th percentile matters
|
|
more than the average.
|
|
|
|
### P3. Complexity Awareness
|
|
Algorithmic cost is known. Big-O is a design conversation, not an
|
|
afterthought.
|
|
|
|
### P4. Resource Bounds
|
|
Memory, CPU, I/O, network — all bounded. Unbounded growth is a bug.
|
|
|
|
### P5. Caching with Intent
|
|
Cache what is expensive, stable, and read often. Invalidation is
|
|
designed, not bolted on.
|
|
|
|
### P6. Lazy by Default
|
|
Compute only when needed. Pay only for what is used.
|
|
|
|
### P7. Async When Independent
|
|
Work that does not depend on other work runs in parallel.
|
|
|
|
### P8. Budget Discipline
|
|
Performance is a design constraint. The budget is set, not negotiated
|
|
after the fact.
|
|
|
|
### P9. Perceived Performance
|
|
What the user feels is what matters. A 200ms perceived response beats
|
|
a 50ms measured one with no feedback.
|
|
|
|
### P10. Regression Prevention
|
|
Performance tests catch what functional tests miss. The slow path
|
|
is tested as a path. |