Performance
Memory hierarchy: why the same O(N) loop can be 17x slower
Two engineers benchmark a list of 1 million numbers. Both loops are O(N). One takes 2 ms, the other 35 ms. Big-O predicts them equal. The CPU disagrees — by 17x.
The memory hierarchy
A modern CPU is not a uniform memory machine. Data does not sit in one place — it flows through five levels, each faster and smaller than the one below it.
| Level | Size (typical) | Latency | Who controls it |
|---|---|---|---|
| Register | ~16 × 8 bytes | <1 cycle | Compiler / CPU |
| L1 cache | 32–64 KB per core | ~1 ns (3–5 cycles) | Hardware |
| L2 cache | 256 KB–2 MB per core | ~3 ns (10–15 cycles) | Hardware |
| L3 cache | 4–64 MB shared | ~10 ns (30–50 cycles) | Hardware |
| Main memory (DDR5) | GBs | ~70–100 ns | OS + allocator |
The number that matters most: L1 is 100x faster than RAM. A single cache miss to main memory costs as much as ~30 floating-point multiplications would take in registers.
The library metaphor
Think of a library with five storage zones. 10 books are on your desk (L1), 100 on a nearby shelf (L2), 10 000 in the same room (L3), and 10 million in a warehouse two blocks away (RAM). A “fast” algorithm that needs to walk to the warehouse for every step loses to a “slow” algorithm that processes every book on the desk in order. Distance matters more than operation count.
Cache lines: the unit of transfer
Data does not move between RAM and cache one byte at a time. It moves in cache lines — 64 bytes on x86 and most ARM chips. Reading one byte at address X loads bytes X through X+63 into cache. Every subsequent read of any byte in that range is a free L1 hit.
This is why sequential access patterns are fast: after the first load, the next seven or eight reads cost almost nothing. The hardware fires proactively — before you ask for byte 64, the prefetcher already loaded that line.
Array vs linked list: the canonical case
Both data structures hold a million integers. Both require N iterations. Big-O says equal. The benchmark says 17x different.
- An array is one contiguous allocation. Elements sit at fixed offsets: address, address+8, address+16, … The prefetcher reads cache lines ahead of your loop. Each element is in L1 by the time the loop reaches it. Cost per element: ~1 ns.
- A linked list allocates each node separately on the heap. The
.nextpointer in each node points to a random location. The prefetcher cannot predict this. Every pointer dereference likely hits a cold cache line at L3 or RAM. Cost per node: ~100 ns.
1 000 000 × 100 ns = 100 ms. The array case: ~1 ms. The 17x benchmark gap is conservative — it assumes some hits from recently-touched nodes. At larger sizes the gap widens.
Why this works
Big-O is defined as asymptotic — it tells you how cost grows with N, not the absolute cost. The hidden constant in front of the N is what the memory hierarchy controls. A well-placed O(N) can have a constant of 1 ns; a pointer-chasing O(log N) can have a constant of 100 ns per step, making the O(N) win until N is in the millions.
Why can an O(N) array iteration beat an O(log N) tree traversal in real benchmarks?
What is a cache line?
Order the levels of memory the CPU accesses, from fastest to slowest:
- 1 Register (inside the CPU core)
- 2 L1 cache (per core, ~1 ns)
- 3 L2 cache (per core, ~3 ns)
- 4 L3 cache (shared, ~10 ns)
- 5 Main memory / RAM (~70–100 ns)
Fill in the blank: when memory accesses are sequential, the CPU's hardware _______ predicts and pre-loads the next bytes before you ask for them.
- 01In one paragraph: why is the iteration cost of a linked list of 1 million nodes 17x slower than an array of 1 million numbers, when both are O(N)?
- 02What is a cache line, and why does it make sequential access patterns much cheaper than random access patterns?
A modern CPU has five memory levels separated by up to 100x latency gaps; data in L1 costs 1 ns, data in RAM costs 70–100 ns. The hardware works in 64-byte cache lines: one read fills a line, making sequential accesses cheap and random accesses expensive. An array of 1 million integers iterates 17x faster than a linked list of the same size because array elements live in contiguous memory — the prefetcher fills cache lines ahead of the loop — while linked list nodes scatter across the heap and each pointer dereference lands in cold memory. Big-O counts operations; the memory hierarchy decides the price per operation. Data layout is the first lever in production performance work.
appears again in159
- The journey of a request: seven stops from socket to responsejunior
- Accept and parse: from kernel queue to a typed requestmiddle
- Routing and middleware: choosing what runs, and in what ordermiddle
- Handler and response: from business logic to bytes on the wiremiddle
- Streaming and backpressure: when the client reads slower than you writesenior
- Timeouts and tail latency: budgets, deadlines, and the fan-out trapsenior
- Middleware and DI: the two patterns that shape every backendjunior
- Writing middleware: signatures, next(), and the three framework modelsmiddle
- Inversion of control: how dependencies reach a classmiddle
- DI scopes and lifecycles: singleton, request, transientmiddle
- DI as a testing seam: fakes, mocks, and the boundary that matterssenior
- DI containers in production: resolution graphs, circular deps, and when not tosenior
- Blocking vs non-blocking I/O: two ways to waitjunior
- The event loop: one thread, ordered phasesmiddle
- What blocks the loop: CPU work and sync callsmiddle
- Offloading CPU work: worker threads and the libuv poolmiddle
- Backpressure and bounded concurrencysenior
- Throughput under load: tail latency and saturationsenior
- Why pool: the cost of creating a connectionjunior
- Pool sizing: why bigger is not fastermiddle
- Acquisition and timeouts: the wait queue is the real latency dialmiddle
- Retry strategies: backoff, jitter, and thundering herdmiddle
- Observability, production failures, and global-scale designsenior
- Tasks, microtasks, and scheduler.yield()middle
- Timer accuracy, throttling, and idle workmiddle
- Node.js event loop: phases, nextTick, and loop lagsenior
- Rendering strategies: SSG, SSR, ISR, streaming, and hydrationjunior
- SSG, SSR, ISR, streaming, and RSC — how each worksmiddle
- Hydration cost: selective, progressive, islands, resumabilitymiddle
- Core Web Vitals: what LCP, INP, and CLS measurejunior
- LCP: four phases, one dominant costmiddle
- INP: input delay, processing, presentationmiddle
- Lab vs field: why the two disagree and how to use eachmiddle
- Metric tradeoffs, RUM attribution, and the CI+field loopsenior
- The full picture: URL to LCP to INP as a relay racejunior
- Eight layers traced: from the service worker to the second navigationmiddle
- Five canonical breaks: where production reliably diessenior
- The three-track method: reading traces and building a monitored systemsenior
- What an index is and how it speeds up queriesjunior
- The leading-column rule and composite index designmiddle
- Partial, expression, and covering indexesmiddle
- Index types: GIN, GiST, BRIN, Hash, Bloom, and HOT updatesmiddle
- Index-only scans, the Visibility Map, and INCLUDEsenior
- Production failure modes and the index audit playbooksenior
- Index design exercise: full-text search strategysenior
- EXPLAIN and execution plans: what the planner decides and whyjunior
- Scan types: Seq, Index, Bitmap, Index-Onlymiddle
- Join algorithms and the row-estimate cascademiddle
- pg_statistic, ANALYZE, and production observabilitymiddle
- Extended statistics: fixing correlated-column estimate failuressenior
- Plan cache, cost-constant tuning, and planner internalssenior
- Production failure modes and plan stabilitysenior
- Connection pools: amortising the cost of a Postgres backendjunior
- PgBouncer session, transaction, and statement modesmiddle
- Pool sizing: the (cores × 2) + spindles formula and the two-layer stackmiddle
- Pool exhaustion and idle-in-transaction: the 3 AM failure modemiddle
- Migrating to transaction mode: rollout playbook and PgBouncer 1.21 prepared statementsmiddle
- The Postgres process model and why raising max_connections degrades throughputsenior
- Pooler landscape 2026, serverless connection storms, and the full failure-mode taxonomysenior
- ADD COLUMN: instant in PG 11+ vs rewrite in older Postgresjunior
- The lock-queue failure mode: why instant DDL can freeze the databasemiddle
- Safe DDL patterns: NOT VALID, CONCURRENTLY, and unsafe-op fixesmiddle
- Migration failure taxonomy and production disciplinesenior
- Shard-key selection: hash, range, list, and directory strategiesmiddle
- Co-location and Citus: the invariant that makes sharding usablemiddle
- The hot-shard failure mode: detection, isolation, and durable policymiddle
- Online resharding, 2PC, and the operational cost of shardingsenior
- The seven acts: from CREATE TABLE to Citusjunior
- Acts 1–3 in depth: schema, indexes, and planner statisticsmiddle
- Acts 4–6 in depth: MVCC bloat, connection pooling, and safe migrationsmiddle
- Act 7 in depth: sharding, co-location, and the seven-tier tradeoff cascademiddle
- Observability, anti-patterns, and production triagesenior
- Bits on the wirejunior
- Latency mathmiddle
- Bufferbloat and congestionsenior
- The physical frontiersenior
- Sequence numbers and connection statemiddle
- Flow control and congestion controlmiddle
- BBR, production observability, and beyond TCPsenior
- CDN: putting content next doorjunior
- Anycast and GeoDNS: routing to the nearest edgemiddle
- Tiered cache and Cache-Controlmiddle
- Vary header and cache keysmiddle
- Stale-while-revalidate and cache stampedesenior
- Edge workers and edge-side compositionsenior
- CDN operations and observabilitysenior
- WebSocket: the HTTP upgrade handshakejunior
- WebSocket vs SSE vs long-polling: choosing the right transportmiddle
- WebSocket backpressure: when clients can''''t keep upmiddle
- Reconnection: jittered backoff, thundering herd, message resumptionsenior
- WebSocket at scale: HTTP/2 multiplexing, permessage-deflate, C10Msenior
- WebSocket in production: proxies, security, and distributed architecturesenior
- What reverse proxies dojunior
- Balancing algorithms: round-robin to power-of-two-choicesmiddle
- L4 vs L7 load balancing and client-IP preservationmiddle
- Health checks, connection draining, and slow startmiddle
- Retry storms, circuit breakers, and load sheddingsenior
- Resilient LB architecture: anycast, zone-aware routing, and observabilitysenior
- Why QUIC and not TCP+TLSjunior
- QUIC streams and head-of-line blockingjunior
- Integrated handshake and 1-RTTmiddle
- Connection IDs and network migrationmiddle
- Loss detection and congestion controlmiddle
- 0-RTT resumption and packet encryptionsenior
- Deployment tradeoffs and CPU costsenior
- DDoS: what it is and why it worksjunior
- Amplification attacks and state exhaustionmiddle
- Rate limiting: algorithms and architecturemiddle
- WAFs, firewalls, mTLS, and HSTSmiddle
- DNS cache poisoning and BGP hijackingsenior
- Defense-in-depth architecture and attack economicssenior
- The twelve layers: one URL, seven actorsjunior
- DNS, TCP, TLS in sequence: where the milliseconds gomiddle
- Critical render path and Core Web Vitalsmiddle
- Proxy intercepts and security gates: rate limiters, WAF, mTLSmiddle
- Alternate paths: QUIC 0-RTT, WebSocket upgrade, connection migrationmiddle
- Observability: distributed traces, USE/RED, and samplingsenior
- Resilience: cascading retries, circuit breakers, and error budgetssenior
- What the three signals are: logs, metrics, and tracesjunior
- Metrics and cardinality: the cost model of a time-series databasemiddle
- Logs and volume: the cost model of structured loggingmiddle
- Traces and sampling: the cost model of distributed tracingmiddle
- Join keys and exemplars: making the three signals composemiddle
- Observability 2.0: wide events and the cost shiftsenior
- Failure modes and engineering practice: cardinality budgets, PII, and samplingsenior
- Why structured logs exist: the diary vs the spreadsheetjunior
- The production log schema: fields every line must carrymiddle
- Log levels and alert routingmiddle
- Sampling strategies and log costmiddle
- PII redaction and log injectionsenior
- Trace context propagation in logssenior
- OTel Logs Data Model and audit logs as a subsystemsenior
- OTel signals, Semantic Conventions, and the OTLP wire formatmiddle
- Auto-instrumentation and manual spans: the 80/20 of OTelmiddle
- The OTel Collector: receivers, processors, exporters, and deployment patternsmiddle
- Sampling strategies: head, tail, and parent-basedmiddle
- Vendor neutrality, eBPF instrumentation, the Operator, and browser/serverless OTelsenior
- Operating the OTel Collector: reliability, version skew, failure modes, and governancesenior
- RED and USE: two checklists, one triage disciplinejunior
- Instrumenting RED in Prometheus: counters, histograms, and cardinality disciplinemiddle
- USE on Linux: CPU, memory, disk, network, and PSImiddle
- Golden signals, dashboard layout, and service mesh auto-REDmiddle
- Cardinality as a cost driver: labels, PII, exemplars, and samplingmiddle
- Native histograms, SLO tie-in, and production failure patternsmiddle
- Choosing SLIs and SLO targets: ratios, not feelingsmiddle
- Multi-window multi-burn-rate alerting: why AND beats ORmiddle
- Error budget policy, latency SLOs, and composite journeysmiddle
- Iceberg SLIs, composite SLO math, and SLA vs SLOsenior
- Flame graphs: reading the picture that shows where time goesjunior
- Sampling vs instrumentation profiling: why 99 Hz wins in productionmiddle
- Profile types: CPU, memory, off-CPU, mutex — which one to reach formiddle
- Continuous profiling: always-on flame graphs with eBPF and trace-id correlationmiddle
- How flame graphs are built from samples, and the production workflows that use themmiddle
- Linux perf, eBPF internals, PGO, and the limits of samplingsenior
- Profiling in production: security, war stories, OTel profiles, and the infrastructure designsenior
- The debugging funnel: SLO → RED → trace → profilejunior
- OTel architecture: one SDK, four signals, one wire formatmiddle
- Cost discipline: keeping observability under 5% of infra spendmiddle
- Scale, security, and the ROI of observable systemssenior