Performance

Go's escape analysis decides where your variables live, and reading its output changed how I write performance-sensitive code

A hash table that benchmarked beautifully in isolation was five times slower under realistic load, and L2 cache misses explained why

I was sure one version of a hot loop was faster; I was wrong; it was the CPU making me look smart

Attaching perf to a JVM produces garbage unless you tell perf where the JIT-compiled symbols are.

Acquire, release, relaxed, sequential consistency — I finally have an intuition for when to use which

pprof.Labels lets you tag goroutines and filter flamegraphs by tag.

GOMEMLIMIT is the Go runtime environment variable I wish I'd known about a year earlier

After waffling for months, I have a rule for when to use dyn Trait and when to use impl Trait, and it holds up

A collection of ways I made Go benchmarks lie to me, including the compiler optimizations I didn't know existed

When your query spills to disk, it's using temp_buffers. The default is 8MB, which is small.

The buffers flag tells you how much of your query was served from cache vs disk.

Converting a concrete type to an interface is not free, and in hot paths it can account for a startling share of GC pressure

A CPU profile pointed at a line with a simple map lookup, and pprof's disasm view sent me down a real rabbit hole

A long rant about what sync.Pool actually guarantees, when it helps, and when it just gives you the illusion of helping

An evening with GODEBUG=schedtrace=1000 taught me more about what my service was actually doing than a month of metrics