On Fri, May 12, 2017 at 4:55 PM T L <tapir....@gmail.com> wrote: > > The 100µs is STW duration. I mean the fps may decrease some during the > period of GC running. >
This is true. But if a refcounter needs to use a bit of CPU power in the background to eventually collect data then it has the same problems with fps drops. And in general, refcount maintenance is more expensive than maintaining GC. There is a bit more instruction pressure in a system with refcounting. I've mentioned "A unified theory of Garbage collection' by Bacon, Cheng, and Rajan (2004) before. In that paper they conjecture that refcounting and (mark'n'sweep) garbage collection are each others duals and that they tend to converge to the same methods. In short: it doesn't matter that much if you use one of the other in practice. I'd have absolutely no qualms on using Go for a game now. A 100us stw pause can easily be hidden in a 16.7ms frame rendering time. And if you ask the GC itself, it usually reports how much time it is spending. I'd be much surprised if you don't have 16ms available per frame even in the worst situation. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
