10 Powerful Performance‑Optimization Techniques You Should Try

Introduction

Software design is an art of trade‑offs: higher performance often means higher implementation cost and may conflict with other quality attributes such as security, scalability, or observability. Before a system hits a bottleneck, developers can apply a set of well‑known techniques to reach the expected performance level.

Time‑Space Trade‑Offs

Performance optimization frequently involves exchanging time for space or vice‑versa. The article splits the discussion into two parts: six generic techniques and four advanced, parallelism‑focused techniques.

Six Generic Techniques

Indexing

Indexes use extra storage to reduce query time, turning O(n) scans into O(log n) or O(1) lookups. Common index structures include hash tables (O(1) lookups), red‑black trees (binary search trees), B‑Tree (used by MongoDB), B+‑Tree (used by MySQL), LSM‑Tree (used by many NoSQL stores), Trie (prefix search, URL routing), skip lists (used by Redis ZSet), and inverted indexes (used by Elasticsearch and Prometheus). When designing database schemas, choose primary keys wisely: auto‑increment IDs offer the best performance but lack global uniqueness; UUIDs are globally unique but larger. A practical compromise is Snowflake IDs, which are globally monotonic yet compact.

Caching

Caching follows the same principle—spending extra storage to save time. The article enumerates multiple cache layers (DNS, OS, CDN, server‑side KV stores, CPU caches, etc.) and warns that cache is not a silver bullet. Cache invalidation, penetration, breakdown, and avalanche are classic problems; solutions include empty‑value caching, Bloom filters, request coalescing, random TTL, and careful invalidation across layers.

Compression

Compression trades CPU cycles for reduced data size. Use gzip/deflate in HTTP Accept‑Encoding, HPACK for HTTP/2 headers, JS/CSS minification, binary encoding for RPC, and compress large objects before storing them in caches. Lossless compression is limited by information entropy; lossy compression (e.g., video transcoding, JPEG, MP3) sacrifices fidelity for bandwidth savings.

Prefetching

Prefetching anticipates future data needs and loads them ahead of time, improving perceived latency at the cost of extra work up front. Typical scenarios include video buffering, HTTP/2 server push, client‑side pre‑loading, server‑side hot‑data warm‑up, and pre‑allocation of resources such as distributed IDs.

Peak‑Shaving (削峰填谷)

Peak‑shaving smooths traffic spikes by delaying work to off‑peak periods. Techniques include front‑end lazy loading, back‑pressure (rate‑limiting, leaky bucket), message‑queue buffering, staggered cron jobs, and exponential back‑off retries for error storms.

Batch Processing

Batching aggregates many small operations into a larger one, reducing per‑item overhead. Examples range from bundling JS assets, using Redis MGET/MSET (optimal batch size 50‑100 keys), bulk INSERT in MySQL/Oracle (≈5 000‑10 000 rows), to sending messages in batches (<1 MB for most cloud queues). The downside is added complexity and potential transaction or concurrency issues.

Four Advanced Techniques (Parallelism‑Focused)

Resource Squeezing (八门遁甲)

Reduce unnecessary system calls, context switches, and I/O wait. Use epoll‑driven event loops, zero‑copy DMA, CPU affinity, and avoid over‑scheduling. References to StackOverflow discussions on context‑switch and system‑call overhead illustrate the impact.

Horizontal Scaling (影分身术)

Scale stateless services by adding replicas behind a load balancer, employing auto‑scaling based on metrics, and ensuring read‑heavy workloads benefit from CDN‑style replication. Amdahl’s law is cited to explain the limits of scaling.

Sharding (奥义)

For stateful components, split data across shards. Discusses Java 1.7 ConcurrentHashMap segment locks, choosing partition keys, handling hot spots with multi‑level caches, and separating hot and cold data (SSD vs HDD). Sharding introduces coordination complexity.

Lock‑Free Techniques (秘术)

Locks become bottlenecks in high‑concurrency scenarios such as inventory or ticketing. The article advocates avoiding race conditions via optimistic locking, CAS‑based data structures (e.g., Java 8 ConcurrentHashMap), lock‑free pipelines, and reducing lock granularity.

Conclusion

Performance work should be guided by ROI: invest early in design, use profiling tools (CPU flame graphs, vmstat, iostat, netstat), and iteratively apply the most cost‑effective optimizations. Over‑optimizing early can waste effort; focus on the 80 % impact techniques first. As Brendan Gregg warns, avoid premature or excessive optimization.