[go-nuts] Re: go 1.13.1 (linux x64): Build and Test is slower.

Hey Stuart, I believe that it is most likely Go modules, I had tested adding go modules to my project and immediately my build times went from almost instant to noticeable. I reverted, and the build times went back to normal. I think this is because Go modules checks for module updates on each

Re: [go-nuts] Doubts regarding implementation of runtime profiler

Implementation in http/net/pprof library is leading me to conclude that they are different. Yes, In runtime/pprof block, mutex, cpu all are implemented in the same way, but http/net/pprof is not using them in the same way. In CPU profiling rate is set internally, while in block, mutex we are suppos

[go-nuts] [ANN] fxamacker/cbor v1.0 and v1.1 ( CBOR library in Go)

CBOR is a concise binary alternative to JSON, and is specified in RFC 7049. fxamacker/cbor is a CBOR library that is: - *Easy* -- idiomatic API like Go's encoding/json. - *Safe and reliable* -- avoids Go's unsafe, has 95+% coverage, and passes 10+ hr

[go-nuts] golang to fpga compilation

xilinx release fpga production for cloude service now , if golang can be compiled to fpga , that would be a su exciting future . Does anyoneo have any suggestions for development of compilation for golang to fpga ? -- You received this message because you are subscribed to the Google Gr

Re: [go-nuts] Doubts regarding implementation of runtime profiler

On Sun, Oct 20, 2019 at 12:51 AM Nidhi Agrawal wrote: > > I came to this conclusion because the pprof implemented the cpu with the > assumption that the client gives how much time to capture the profiling data. > but when it comes to the mutex and block, the pprof didn't implement it to > suppo

Re: [go-nuts] Doubts regarding implementation of runtime profiler

I came to this conclusion because the pprof implemented the cpu with the assumption that the client gives how much time to capture the profiling data. but when it comes to the mutex and block, the pprof didn't implement it to support this but asked the client to call the profile rate before calling

Re: [go-nuts] Doubts regarding implementation of runtime profiler

On Sun, Oct 20, 2019 at 12:36 AM Nidhi Agrawal wrote: > > Because it is explicitly written in the documentation here > https://golang.org/pkg/net/http/pprof/ that we should set block profile rate > at the start of application, unlike CPU profiling where the rate is being set > internally before

Re: [go-nuts] Doubts regarding implementation of runtime profiler

Because it is explicitly written in the documentation here https://golang.org/pkg/net/http/pprof/ that we should set block profile rate at the start of application, unlike CPU profiling where the rate is being set internally before profiling starts. As you said we can set the rate any time then si

Re: [go-nuts] Doubts regarding implementation of runtime profiler

On Sun, Oct 20, 2019 at 12:23 AM Nidhi Agrawal wrote: > > Ok, Is it necessary to call SetBlockProfileRate at the start of application? > If not then we can call it just before starting block profile and after block > profile interval (eg. 30 seconds) when profiling finishes then we can reset > i

Re: [go-nuts] Doubts regarding implementation of runtime profiler

Ok, Is it necessary to call SetBlockProfileRate at the start of application? If not then we can call it just before starting block profile and after block profile interval (eg. 30 seconds) when profiling finishes then we can reset it to 0. On Sun, Oct 20, 2019 at 12:48 PM Ian Lance Taylor wrote:

Re: [go-nuts] Doubts regarding implementation of runtime profiler

On Sat, Oct 19, 2019 at 10:17 PM Nidhi Agrawal wrote: > > > https://golang.org/src/runtime/mprof.go, > https://golang.org/pkg/net/http/pprof/ here it is mentioned that we need to > set SetBlockProfileRate to get enable block profile. > > In case of block profiling if I set rate just before profi