6 ms·
> Fair, but you almost never see things like this with Go, and when you do, it's pretty straightforward to triage since the GC and escape analysis are far simpl
by jashmatthews 9y ago
> Fair, but you almost never see things like this with Go, and when you do, it's pretty straightforward to triage since the GC and escape analysis are far simpler.
The Go GC is not a panacea. It trades lower STW pause times for a huge drop in throughput under GC pressure and simplicity for terrible performance with large, mostly static heaps when compared to a generational collector.
This entire discussion and the original article is worth reading: https://www.reddit.com/r/programming/comments/5fyhjb/golangs_realtime_gc_in_theory_and_practice_pusher/dapa17l/ https://www.reddit.com/r/programming/comments/5fyhjb/golangs...
- weberc2 9y agoAgreed. My point is that those tradeoffs are really, really good for a huge swath of applications.
- jashmatthews 9y agoI'm not sure that's true. It works well for web proxies and simple CRUD apps. Anything which needs a decently sized heap is multiple times slower than Java, OCaml etc. CockroachDB only works at all because the actual DB is in RocksDB written in C++.
- weberc2 9y agoI don't know what constitutes "decently sized", but I've not had significant issues with a 12GB heap.