I agree with the poster below. GC's problem isn't speed, per se; the problem is that GC only works effectively if you assume infinite memory and cache. Once you start approaching memory limits you start feeling pain.
Is it just me or does every GC is faster argument boil down to: "All working real world examples are noticeably slower, but trust me, I know of this amazing GC that's actually faster it's just not in production use anywhere yet."
To be fair, we do that to avoid GC slowdown issues. If the GC improves to the point where that's no longer an issue, we don't have to do that anymore :)
Yes, slower than modern GC, but predictable and deterministic. Note that the parent comment never claimed it was faster, just that it avoids 'stop the world' which can be a problem in realtime contexts (e.g. games, audio).
I had already done a bit of profiling: originally the GC was taking up around 40% of the total running time, and I managed to reduce it to 10% by removing the biggest source of allocations. As it's not latency-critical there wasn't an immediate need for further optimisation.
This doesn't read like a "GC is slow" problem to me, more like a "GC doesn't cope well in the face of a highly concurrent allocation workload". That's pretty bad though. As soon as you go down the rabbit hole of tweaking knobs to cajole GC into doing what you expect, darkness lies beyond..
Yes, you can spend a large amount of time making things faster. But note that Go's GC is fast, even though it is simple. It's not the fastest, but it is acceptably fast.
Precisely. That’s why I was suspicious of this claim that there is a GC out there that is both "extremely fast" and has "minimal pauses". Something’s got to give.
Very misleading title. This is not about a GC speed up, it is about a reduction in pause time. The GC a itself is eating as many cycles as before (possibly more due to the cost of making things incremental) and they are clear about this in the article.
Yeah, I suspect a good chunk of the performance improvement is related to GC performance improvement. The netty benchmark with pooled buffers compared to unpooled buffers hints at that (although I don't know for sure).
reply