5 ms·
Of course gains are to be expected when switching from Java's default GC to something specialized. > 25% GC overhead in older versions of Go, that's utterly te
by hu3 8y ago
Of course gains are to be expected when switching from Java's default GC to something specialized.
> 25% GC overhead in older versions of Go, that's utterly terrible.
25% overhead of what? And compared to what? Just throwing numbers in the air and saying it's terrible makes no sense.
The only 25%'s if could find in the slide were these: https://blog.golang.org/ismmkeynote/image6.png https://blog.golang.org/ismmkeynote/image6.png
2014 Go: 25% of CPU used by GC
2018 Go: 25% of CPU used during 2x STW GC of < 500 microseconds
So even if STW GC occurred as frequent as every second (which it doesn't in my use cases), this would amount to 0.025% of the CPU being used for GC, not 25%.
- the8472 8y agoThe 2014 numbers read to me that 25% of all CPU cycles are spent on GC. If you re-read my previous post I was talking about that old version. The point was that Go started improvements from a fairly bad place, were gains are still relatively easy to obtain. > Of course gains are to be expected when switching from Java's default GC to something specialized. So? That's irrelevant for what's state of the art.
- hu3 8y agoI re-read our conversation thread to understand our communication mismatch and indeed you were taking about Go's GC not being novel, which it isn't. I apologize for the unproductive conversation, it's all on me.