4 ms·
I wonder how the GC pause times and throughput compare. My understanding is that Go sacrifices some compute performance for better GC pause times.
by piinbinary 6y ago
I wonder how the GC pause times and throughput compare. My understanding is that Go sacrifices some compute performance for better GC pause times.
- dgb23 6y ago> better GC pause times What does that mean exactly / in this case? My assumption is that "better" means more predictable. Or does it mean straight up fewer/shorter?
- recursivecaveat 6y agoGo sacrifices basically every other GC metric to minimize average pause times. Sortof a 'if you can't succeed, redefine success' mentality if you will.
- sharpy 6y agoThat's not necessarily a bad thing for writing web services. I used to spend a fair bit of time tuning JVM to achieve acceptable tail latencies for Java services, not to mention once in a while, they would need to be tuned again... Not so with Go.
- apta 6y agoJava now has two low latency collectors: ZGC and Shenandoah.
- jashmatthews 6y agoThe Go GC and the JVM GCs are built within very, very different constraints. Since most short-lived allocations in Go are stack-allocated, the cost of adding a read-barrier and branching on every heap access is more expensive than the potential gain from bump-pointer allocation.
- mr_aks 6y agoIn Go's case, it means that GC pauses are shorter because it uses a concurrent mark and sweep algorithm.
- gen220 6y agoRick Hudson gave this excellent keynote on some of the "recent" (as of 2018) improvements and guiding principles for Go's GC, if you're interested in the nitty-gritty. https://blog.golang.org/ismmkeynote https://blog.golang.org/ismmkeynote He outlines the SLOs for the garbage collector, with the motivation that this SLO impacts the SLOs/time budget of every application built with Go. They key metrics are "share of CPU used for GC", heap sizes, latency and frequency of pauses, and scaling favorably with go-routine allocations.