2 ms·
Most generational GCs will work better if you don't reuse objects - reuse extends lifetime and increases probability of promotion to an old generation, slower t
by barrkel 8y ago
Most generational GCs will work better if you don't reuse objects - reuse extends lifetime and increases probability of promotion to an old generation, slower to scan. (Go's GC is not generational today, AFAIK.) I'd take any recommendations along those lines as last resort techniques to reduce pressure on critical path loops. And a more sophisticated runtime may allocate such temporaries in registers or on the stack.
In other words, you're tuning to today's runtime if you reuse heavily. Those techniques may not age well, and will harm readability and maintainability.
- ainar-g 8y ago>Go's GC is not generational today, AFAIK. It isn't, and will probably never be. The Go runtime developers have actually implemented and tested a generational GC, but found that it's not useful, and even harmful at times, to the goal of having fast, low-latency, concurrent garbage collector. Mostly because most short-lived objects are allocated on stack, and the escape analysis is getting better with each release. See https://blog.golang.org/ismmkeynote https://blog.golang.org/ismmkeynote.
- pcwalton 8y agoThe generational GC that the Go team implemented does not offer one of the primary benefits of generational GC: bump allocation in the nursery. Without that benefit, it's an unfair comparison. This benefit is directly relevant to this thread, because bump allocation in the nursery makes the allocation fast path somewhere on the order of 6 instructions.