Any memory management strategy costs time. Reference counting is not cheap. Incrementing and decrementing millions of reference counters costs time. Please consider caching issues as well.
Go GC, as it currently stands, is very effective, as other people in this forum can confirm to you. Several Gigs of data and the only way to perceive any performance impact is by generating a profile chart! Only a practical test, tailored to your case, could tell if Go GC could degrade your fps. If by any chance you find a challenging situation I am sure the Go Team would be very eager to investigate, because it is increasingly difficult to find new challenges to the GC. On Friday, May 12, 2017 at 11:55:36 AM UTC-3, T L wrote: > > > > On Thursday, May 11, 2017 at 8:48:05 PM UTC+8, JuciÊ Andrade wrote: >> >> Maybe a 100µs GC would be fast enough for you to be at easy with your >> game FPS. >> >> >> https://groups.google.com/forum/#!searchin/golang-dev/garbage$20collector$20microseconds%7Csort:relevance/golang-dev/Ab1sFeoZg_8/_DaL0E8fAwAJ >> >> > The 100µs is STW duration. I mean the fps may decrease some during the > period of GC running. > > >> On Friday, May 5, 2017 at 12:10:01 AM UTC-3, T L wrote: >>> >>> ARC would be a better option for game apps than GC, to keep the fps >>> stable. >>> >> -- 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.
