Less known Go runtime details that affect performance

When I was working with Go, sometime ran into a few runtime behaviors that were not always obvious at first but could have a real impact on performance. These aren’t beginner mistakes, they tend to show up once you’re dealing with higher load or more constrained environments.

One of the first times I noticed this was when I was processing a high volume of device updates. The system used goroutines to handle incoming events, and for the most part it worked well. But every so often there would be noticeable pauses. After some profiling, it became clear that the garbage collector was kicking in frequently and causing latency spikes.

By default, Go’s garbage collector becomes more aggressive as the heap grows. In this case, it was running often enough to interrupt the flow of real-time processing. I adjusted the GOGC environment variable to make the collector less aggressive, which reduced the frequency of pauses. The trade-off was higher memory usage, so I also started reusing temporary objects with sync.Pool instead of allocating new ones for every request. This combination helped keep latency more consistent without letting memory grow out of control.

var devicePool = sync.Pool{
    New: func() any {
        return &DeviceData{}
    },
}

func handleDeviceUpdate(data *DeviceData) {
    obj := devicePool.Get().(*DeviceData)
    *obj = *data
    // process the data...
    devicePool.Put(obj)
}

Another situation came up when I was working with a C library to handle data from an IoT device. Using cgo made sense at first because the C code was already fast and well-tested. However, over time I started seeing memory issues and occasional instability that were hard to debug. The Go runtime doesn’t manage memory allocated in C, which can lead to leaks and fragmentation if you’re not extremely careful. Eventually, I rewrote the critical parts in pure Go. I used encoding/binary to parse the incoming data instead of relying on cgo for the hot path. It wasn’t quite as fast in raw benchmarks, but the system became much more stable and easier to maintain. In edge environments with limited resources, the reliability gain was worth the small performance difference.

func processSensorData(data []byte) error {
    var parsed struct {
        Temp     float32
        Humidity uint16
    }
    if err := binary.Read(bytes.NewReader(data), binary.LittleEndian, &parsed); err != nil {
        return err
    }
    // process parsed data...
    return nil
}

I would say that Go’s performance isn’t only about writing efficient code and about concurrency, it’s also about understanding how the runtime behaves under load. Tuning the garbage collector and being cautious with cgo are two areas that can make a noticeable difference once your system starts handling real traffic or runs on constrained hardware.

So even small optimizations in Go’s runtime can make a big difference in user experience.