Golang Pitfalls: Optimizations

Source material: mistakes #91-100 from 100 Go Mistakes and How to Avoid Them (teivah/100-go-mistakes).

Apply these rules when optimizing Go code. Always validate optimizations with benchmarks and profiling before/after.

91. Not understanding CPU caches (#91)

• L1 cache is roughly 50-100x faster than main memory — data layout and access patterns drive CPU-bound performance.
• Cache line: CPUs fetch a block (~64 bytes), not a word at a time. Enforce spatial locality so each fetched cache line is fully used.
• Slice of structs vs. struct of slices: the layout matters — iterate over data laid out contiguously to maximize cache-line utilization.
• Predictability: unit/constant strides are predictable for the CPU (prefetching); non-unit strides (linked lists) are not.
• Cache placement policy: caches are partitioned; a critical stride can map everything to few sets, using only a tiny portion of the cache.

92. Writing concurrent code that leads to false sharing (#92)