←back to thread

Go Optimization Guide

(goperf.dev)
480 points jedeusus | 2 comments | 31 Mar 25 20:29 UTC | HN request time: 0.015s | source
Show context
nopurpose ◴[31 Mar 25 22:34 UTC] No.43540684[source]▶
Every perf guide recommends to minimize allocations to reduce GC times, but if you look at pprof of a Go app, GC mark phase is what takes time, not GC sweep. GC mark always starts with known live roots (goroutine stacks, globals, etc) and traverse references from there colouring every pointer. To minimize GC time it is best to avoid _long living_ allocations. Short lived allocations, those which GC mark phase will never reach, has almost neglible effect on GC times.

Allocations of any kind have an effect on triggering GC earlier, but in real apps it is almost hopeless to avoid GC, except for very carefully written programs with no dependenciesm, and if GC happens, then reducing GC mark times gives bigger bang for the buck.

replies(12): >>43540741 #>>43541092 #>>43541624 #>>43542081 #>>43542158 #>>43542596 #>>43543008 #>>43544950 #>>43545084 #>>43545500 #>>43551041 #>>43551691 #
MarkMarine ◴[31 Mar 25 22:40 UTC] No.43540741[source]▶
Are you including in this analysis the amount of time/resources it takes to allocate? GC isn't the only thing you want to minimize for when you're making a high performance system.
replies(1): >>43543762 #
1. nopurpose ◴[01 Apr 25 07:14 UTC] No.43543762[source]▶
From that perspective it boils down to "do less", which is what any perf guide already includes, allocations is just no different from anything else what app do.

My comment is more about "reduce allocations to reduce GC pressure" advice seen everywhere. It doesn't tell the whole story. Short lived allocation doesn't introduce any GC pressure: you'll be hard pressed to see GC sweep phase on pprof without zooming. People take this advice, spend time and energy hunting down allocations, just to see that total GC time remained the same after all that effort, because they were focusing on wrong type of allocations.

replies(1): >>43547860 #
2. MarkMarine ◴[01 Apr 25 15:20 UTC] No.43547860[source]▶
Yeah I understand what you’re saying, but my point is you’re doing the opposite side of the same coin. Not doing full perf analysis and saying this one method works (yours is to reduce GC mark time, ignoring allocation, others are trying to reduce allocation time, ignoring GC time, or all these other methods listed in this doc.)