←back to thread

Go Optimization Guide

(goperf.dev)
480 points jedeusus | 3 comments | 31 Mar 25 20:29 UTC | HN request time: 0s | 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 #
1. deepsun ◴[01 Apr 25 20:33 UTC] No.43551041[source]▶
Interesting, and I think that is not specific to Go, other mark-and-sweep GCs (Java, C#) should behave the same.

Which means that creating short lived objects (like iterators for loops, or some wrappers) is ok.

replies(2): >>43552012 #>>43552485 #
2. int_19h ◴[01 Apr 25 22:36 UTC] No.43552012[source]▶
It should be noted that in C#, at least, the standard pattern is to use value types for enumerators, precisely so as to avoid heap allocations. This is the case for all (non-obsolete) collections in the .NET stdlib - e.g. List<T>.Enumerator is a struct.
3. ted_dunning ◴[01 Apr 25 23:57 UTC] No.43552485[source]▶
Not entirely. Go still doesn't have a generational collector so high allocation rates cause more GC's that must examine long-lived objects.

As such, short-lived objects have little impact in Java (thank god for that!). They will have second order effects in Go.