ok. the short answer is that if you make a few million somethings -- goroutines, channels, whatever -- and they all wait for the first event in order to start, then what is certain is that you'll attain the peak memory usage needed to hold them all at once.
it means the OS will have surrendered that much memory before anything interesting happens. then, once the addition chain is underway, the old routines will be rendered moot one by one and your question becomes four-fold: 1a), when will the Go runtime notice the stale memory, 1b) when will it return that to the OS, and, 2a) when will the OS do something about that released memory region, and, 2b) when will that action be visible in memory statistics. it seems that there can be some delay for 2b in any case. Difference in peak memory use between my version and the original is a measure of 1a and 1b. On Wed, Oct 4, 2017 at 10:15 AM, Unni Krishnan <u...@nilenso.com> wrote: > That's an interesting solution, but what I'm trying to figure out is why > the memory usage is this high and understand how go handles this. > > On Tue, Oct 3, 2017 at 9:16 PM Michael Jones <michael.jo...@gmail.com> > wrote: > >> Or you could do it this way... >> >> https://play.golang.org/p/rU2ONi51ec >> >> On Mon, Oct 2, 2017 at 7:26 PM, Unni Krishnan <u...@nilenso.com> wrote: >> >>> I tried FreeOSMemory, didn't make any difference. >>> >> >>> On Mon, 2 Oct 2017, 5:26 a.m. Ian Lance Taylor, <i...@golang.org> wrote: >>> >>>> On Sat, Sep 30, 2017 at 9:29 AM, <u...@nilenso.com> wrote: >>>> > >>>> > From what I understand reading and a few comments from the gopher >>>> slack, >>>> > this is because go is not releasing memory back to OS but holds it >>>> for a >>>> > longer in case it needs this, if that makes sense? It would be really >>>> > helpful, if someone could help me understand this. >>>> >>>> Yes, that is what the Go runtime does. It requests the memory it >>>> needs from the operating system. Every five minutes or so it returns >>>> unused memory back to the operating system. You can make this happen >>>> sooner by calling https://golang.org/pkg/runtime/debug/#FreeOSMemory . >>>> >>>> Note that on modern operating systems unused memory is quite cheap. >>>> >>>> Ian >>>> >>> -- >>> 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. >>> >> >> >> >> -- >> Michael T. Jones >> michael.jo...@gmail.com >> > -- Michael T. Jones michael.jo...@gmail.com -- 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.
