Career & Craft
Performance Profiling
Measuring where a program actually spends time and memory — with CPU and heap profilers, flame graphs and benchmarks — so you optimise the real bottleneck instead of guessing. The rule is measure first: intuition about hot spots is usually wrong, and premature optimisation wastes effort. Profile, fix the biggest cost, then measure again.
Purpose
Profiling measures where a program actually spends its time and memory — CPU profilers sample the call stack, heap profilers track allocations, flame graphs make the result readable at a glance. It exists because intuition about hot spots is notoriously wrong; the measured bottleneck is rarely the suspected one.
When to Use It
Diagnosing slow endpoints (is it the query, the serialisation, the framework?), memory leaks and GC pressure, startup time, and N+1 database patterns. In the browser, the DevTools profiler plays the same role for render and script cost. Continuous profiling in production catches regressions no benchmark predicted.
Trade-offs
Profilers add overhead and can distort what they measure — sampling profilers keep this small; instrumenting ones trade accuracy of counts for it. Micro-benchmarks mislead without realistic data and warm-up. And the eternal rule stands: optimising before measuring wastes effort on the wrong three percent.
Implementation
Reproduce the slow case under realistic load; profile (language-native tools — Node's --prof/clinic, py-spy, pprof, EXPLAIN ANALYZE for SQL); read the flame graph for the widest frames; fix the single biggest cost; measure again. Repeat until the target is met, and lock the win in with a benchmark or budget in CI.