On Saturday, May 13, 2017 at 12:02:39 AM UTC+8, JuciÊ Andrade wrote: > > 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! >
In fact, the need to ARC is not efficiency, it is predictability and consistency instead. And I don't expect ARC to be the main memory collect way, but I think it can be a supplement. For example, maybe two types, sync.Pointer and sync.WeakPointer can be added. > > 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.
