It is almost never a good idea to call runtime.GC explicitly. It does block until a garbage collection completes. This behavior is sometimes useful in tests, but almost never otherwise. If it weren't for go1 compatibility, we'd rename this function to something that more clearly spells out its blocking behavior.
On Friday, April 21, 2017 at 11:51:17 AM UTC-7, Lee Armstrong wrote: > > Interestingly stackimpact.com just updated their code to remove the > runtime.GC() calls. > > It has made a HUGE difference to the GC pauses. > > The code was updated just before 19:30. > > Interesting that the manual call had such an impact! > > > <https://lh3.googleusercontent.com/-Cfl2uxAbqSk/WPpUa3aDMZI/AAAAAAAA-3k/_g3b1RZp6MYuBOSbeUHlBRbeFTaqeQTKQCLcB/s1600/2017-04-21_19-44-20.png> > > > On Thursday, April 20, 2017 at 2:49:49 PM UTC+1, Lee Armstrong wrote: >> >> See attached graph which shows the GC pauses of an application we have. >> >> I am frequently seeing pauses of 1-1.5 seconds. This is using Go 1.8.1 >> and have a large map that is frequently accessed and items are removed and >> added to it. These can be of some size. >> >> Is there a way to get these pauses down at all? Would forcing a GC() >> after removing a batch of elements help at all? >> >> Alongside the pauses I see some substantial CPU usage showing up in >> traces for the GC scan. >> >> Thanks in advance! >> > -- 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.
