Go Optimization Guide
goperf.dev
Go Optimization Guide
1–10 of 173 posts
Re: Go Optimization Guide
#2Noticed the object pooling doc, had me wondering: are there any plans to make packages like `sync` generic?
Re: Go Optimization Guide
#3Noticed the object pooling doc, had me wondering: are there any plans to make packages like `sync` generic?
eventually: https://github.com/golang/go/issues/71076
Re: Go Optimization Guide
#4Additionally...
- https://go101.org/optimizations/101.html
- https://github.com/uber-go/guide
I wish this content existed as a model context protocol (MCP) tool to connect to my IDE along w/ local LLM.
After 6 months or switching between different language projects, it's challenging to remember all the important things.
Re: Go Optimization Guide
#5Every 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.
Re: Go Optimization Guide
#6Every 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 ne…
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.
Re: Go Optimization Guide
#7You're not really writing 'Go' anymore when you're optimising it, it's defeating the point of the language as a simple but powerful interface over networked services.
Re: Go Optimization Guide
#8Additionally... - https://go101.org/optimizations/101.html - https://github.com/uber-go/guide I wish this content existed as a model context protocol (MCP) tool to connect to my IDE along w/ local LLM. After 6 months or switching between different language projects, it's challenging to remember all the important things.
Additionally...
- https://www.uber.com/en-AU/blog/how-we-saved-70k-cores-acros...
This has saved Uber a lot of money on compute (I'm one of the devs). If your compute fleet is large and has memory to spare (stateless), performing dynamic GOGC tuning to tradeoff higher memory utilization for fewer GC events will save quite a lot of compute.
Re: Go Optimization Guide
#9You can often fool yourself by using sync.Pool. pprof looks great because no allocs in benchmarks but memory usage goes through the roof. It's important to measure real world benefits, if any, and not just synthetic benchmarks.
Re: Go Optimization Guide
#10Every 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 ne…
Aren't allocations themselves pretty expensive regardless of GC?