←back to thread

480 points jedeusus | 1 comments | | HN request time: 0s | source
Show context
nopurpose ◴[] 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 #
zmj ◴[] No.43542081[source]
Pretty similar story in .NET. Make sure your inner loops are allocation-free, then ensure allocations are short-lived, then clean up the long tail of large allocations.
replies(1): >>43542681 #
1. neonsunset ◴[] No.43542681[source]
.NET is far more tolerant to high allocation traffic since its GC is generational and overall more sophisticated (even if at the cost of tail latency, although that is workload-dependent).

Doing huge allocations which go to LOH is quite punishing, but even substantial inter-generational traffic won't kill it.