Performance
508 bites tagged Performance — interview questions with model answers, and 60-second explainers.
API Pagination: Serving Big Datasets in Chunks
API pagination breaks large result sets into smaller chunks to prevent server overload. It's essential for any endpoint returning many records, like a list of users or products.
Node's zlib Module: Trading CPU for Bandwidth
Node's `zlib` module trades CPU cycles for network bandwidth by shrinking data with algorithms like Gzip and Brotli. Use it to compress large API responses or files before sending them. The main footgun: never use synchronous `...Sync` methods in a server.
Node.js File I/O: Synchronous vs. Asynchronous
Synchronous file I/O blocks your app, like waiting at a counter for your order. Asynchronous I/O gets a buzzer, letting your app work on other tasks. Use async for servers and sync for simple, one-off scripts. The footgun is using sync I/O in a server.
Node.js Cluster: Scaling on a Single Machine
The `cluster` module turns a single-threaded Node.js app into a multi-process server that uses all CPU cores. It's ideal for scaling network applications on one machine by sharing a single port.
Worker Threads: True Parallelism in Node.js
Worker threads give Node.js a separate brain for heavy lifting, letting you run CPU-intensive code without blocking the main event loop. Use them for tasks like image processing, not I/O. The footgun is assuming memory is shared; it isn't.
Node.js Streams: Processing Data in Chunks, Not Blobs
Think of streams as a data conveyor belt, processing large files or network data in chunks instead of loading it all into memory. Use them for file I/O or network requests.
JavaScript's Event Loop: Macrotasks & Microtasks
The JavaScript event loop processes tasks like `setTimeout` callbacks or user clicks from a macrotask queue. A single, long-running macrotask blocks all rendering and user input, freezing the UI. The footgun is assuming `setTimeout(fn, 0)` runs instantly.
Universal Scalability Law: The Physics of Scaling
The Universal Scalability Law (USL) models throughput by quantifying the two costs of parallelism: contention and coherency. Use it to forecast performance and diagnose bottlenecks.
Amdahl's Law: The Bottleneck of Parallel Speedup
Amdahl's Law shows a system's speedup is limited by its sequential parts. If 10% of a task must run serially, your maximum speedup is 10x, no matter how many cores you add. This applies to CPUs, databases, and distributed jobs.
Queueing Theory: The Math of Waiting Lines
Queueing theory is the math of waiting lines, helping you predict system performance under load. It's used for capacity planning and setting autoscaling rules.
Critical Path Analysis for Performance Tuning
Critical path analysis finds the slowest chain of operations in a request, showing where to optimize for impact. Use it in distributed tracing to see which service call is the bottleneck. Optimizing off-path components is wasted effort.
Performance Budgets: Set Limits to Stay Fast
A performance budget is a hard limit on metrics like bundle size or load time, acting as a guardrail against regressions. It's used in CI/CD to fail builds that exceed size limits or in monitoring to alert when load times degrade.
Scalability Testing: Will More Hardware Fix It?
Scalability testing answers 'Will more hardware fix it?' by measuring how performance improves when you add resources. The common footgun is confusing it with load testing, which just finds the breaking point under a given load.
Soak Testing: Finding Bugs That Only Time Reveals
Soak testing is like running a marathon, not a sprint, to find bugs that only time reveals. It applies a typical production load over a long period to uncover slow memory leaks or resource exhaustion. The footgun is confusing it with stress testing.
Benchmarking: Know Your System's Limits
Benchmarking finds your system's limits by measuring its responsiveness and stability under a controlled workload. Use it to catch performance regressions, compare tech choices, or for capacity planning. The footgun: trusting benchmarks run on your laptop.
Load Testing: Simulating Real-World User Traffic
Load testing answers 'Can our system handle expected traffic?' by simulating many users at once. Use it before a big launch to find bottlenecks. The footgun is confusing it with stress testing, which pushes a system past its limits to see how it breaks.
Inference Throughput: How Many Predictions Per Second?
Inference throughput measures how many predictions your system can make per second, not how fast a single one is. It's the system's total capacity, critical for high-volume tasks like recommendation engines. The footgun is confusing it with latency.
Inference Batching: Grouping Requests for Throughput
Think of inference batching as a carpool for your ML model. Instead of sending each request in its own car, you wait a few microseconds to fill a bus, dramatically improving GPU efficiency.
LLM Inference Caching: Pay for Computation Once
LLM inference caching reuses past computations to cut costs and latency. It avoids reprocessing shared system prompts or serves full answers for common queries without hitting the model. The footgun: semantic caches can return a "similar" but incorrect answer.
Post-Training Quantization: Shrink Models Without Retraining
Post-Training Quantization (PTQ) shrinks a pre-trained model by converting its weights to lower precision, like turning a WAV file into an MP3. Use it to run large models on consumer GPUs without costly retraining.
Optimizing iOS App Launch Time
An app launch is a race against the system's watchdog timer. The OS loads your app in two phases: pre-main and main. Optimizing both is key. The biggest footgun is ignoring the pre-main phase, where bloated dynamic libraries can kill performance.
On-Demand Resources: Keep Your App Bundle Slim
On-Demand Resources (ODR) host app assets on the App Store, not in your bundle, shrinking your initial download. Use it for game levels or tutorials not needed at first launch. The OS downloads assets by "tag" when requested, but can also purge them to save.
App Thinning: Ship Only What's Needed
App Thinning shrinks your app's download by delivering only the assets a specific device needs. The App Store uses Slicing for device-specific art and code, and you can use On-Demand Resources for assets downloaded after installation.
Static vs. Dynamic Linking: Code Size vs. Flexibility
Static linking bakes library code into your app, creating a large but self-contained executable. Dynamic linking loads libraries at runtime, saving space. This choice impacts app size, launch time, and updates.
Get Performance bites daily.
Five a day, five minutes, offline. With quizzes so it sticks.
Open testing — you’ll join as an early tester.