Re: [go-nuts] Why golang garbage-collector not implement Generational and Compact gc?

The following article showing that a compacting gc can make the application run faster in some cases might be of interest as well: https://shipilev.net/jvm-anatomy-park/11-moving-gc-locality/ -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To u

[go-nuts] Re: Different latency inside and outside

> > > As you can see, your hypothesis is not true, more then 99 percent of > requests is really fast and occur less the 1 millisecond! And I try to find > our what happens in this 1 percent! > > I was probably not clear enough with my explanation. In 99% of cases net/http (or fasthttp) parsi

[go-nuts] Re: Different latency inside and outside

Hi, External measurements probably show more acurate picture. First of all internal latency numbers only include time spent doing actual work but don't include HTTP parsing (by net/http) and network overhead. Secondly latency measured internally always looks better because it doesn't include a

[go-nuts] Re: [Newbie] Why this code is so slow?

int type in Go is 64 bit on 64 bit system . Most likely you are using 32 bit integers in other languages (e.g. int in Java). 64 bit division is slower than 32 bit. Try changing your Go program to use int32 instead and see if it becomes faster. -- You received this message because you are subsc

Re: [go-nuts] Go locking and channels much slower than Java equivalent, program spends most of time in sync.(*Mutex).Lock() and sync.(*Mutex).Unlock()

I don't think defer is the main bottleneck here. I tested the benchmark with Go tip and with removing defers. While it becomes faster it is still slower than Java. I believe that the reason the Java version is faster is that it's lock implementation behaves better under contention. While I am not

Re: [go-nuts] Understanding go routine heap

The code might be race free for the current Go implementation but I don't think this behaviour is documented. https://golang.org/ref/mem doesn't mention sync.WaitGroup at all. So wg.Done() doesn't necessarily happen before wg.Wait() returns and the effect of writing to "result" could be not vi

Re: [go-nuts] How Go GC perform with 128GB+ heap

Even if STW pauses are under 10ms they are not the only source of latency introduced by GC (see for example https://github.com/golang/go/issues/15847, https://github.com/golang/go/issues/16293, https://github.com/golang/go/issues/16432). Some of these issues will be addressed in Go 1.7, others

[go-nuts] Re: Importing a main package

One way to solve this is to send a pull request to the author of the tool that extracts functionality that you want to reuse into a package. This will benefit any future users that are in the same situation. There might be reasons that the author of the tool will be against such change though.