×

One of Go’s greatest strengths is its ability to handle concurrent tasks efficiently. Goroutines introduce minimal overhead and require no complex constructs to manage. However, while goroutines are memory-efficient compared to traditional threads, the garbage collector (GC) can become a bottleneck in allocation-heavy scenarios.

The Problem: GC Overhead

Garbage collection means unpredictable pauses and CPU overhead. But how much can we mitigate this when performance matters?

Test Setup

I allocated 5 million instances of the following struct across 12 goroutines, each with randomized field values:

type Item struct {
    ID    int64
    Value float64
    Data  [256]byte // Placeholder for larger data
}

Benchmark Results

Key Observations

1. Manual pooling wins

• Pre-allocating memory reduced runtime by 54% vs. heap allocation.
• Go’s sync.Pool or custom byte pools avoid GC sweeps for reusable objects.

2. VirtualAlloc isn’t magic

• Direct OS-level allocation (windows.VirtualAlloc) was marginally slower than Go’s manual pooling, likely due to syscall overhead.

3. Go vs. C

• Go’s manual pools achieve ~73% of C’s speed (276 ms vs. 160 ms).
• The gap stems from runtime checks and GC safeguards, even with pooling.

Conclusion

• For most use cases, manual memory pooling (~276 ms) offers the best balance of performance and maintainability.
• Avoid over-optimizing: VirtualAlloc’s complexity rarely justifies its minor gain over Go’s built-in pooling.
• Future alternative: Go’s experimental arenas (1.20+) may simplify manual pooling without sacrificing performance.

Optimizing Go’s memory management isn’t about eliminating GC—it’s about making it irrelevant.

Final Pro Tip: Optimizing Manual Pools

When using a manual memory pool, store values (not pointers) to minimize GC overhead. The Go garbage collector scans pools for reachable pointers—by avoiding them entirely (e.g., using []byte or value-only structs), you effectively create GC-invisible allocations. This can reduce pause times significantly in allocation-heavy workloads.

The complete Go and C code referenced here is available in this GitHub Gist.

Have thoughts on this article? Join the discussion on —I’d love to hear your perspective!