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 the pprof function. This made me question why is there a difference in the profiling technique, is it expected from us to set profile rate at the start of the program, if not then why didn't they implement it similar to the cpu.
On Sun, Oct 20, 2019 at 1:10 PM Ian Lance Taylor <i...@golang.org> wrote: > On Sun, Oct 20, 2019 at 12:36 AM Nidhi Agrawal <nidhi11...@gmail.com> > 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 profiling starts. > > I'm likely missing something, but I'm looking at > https://golang.org/pkg/net/http/pprof, and I don't see that. I see > that it says that you have to call runtime.SetBlockProfileRate or > runtime.SetMutexProfileFraction, but I don't see anything that says > that you have to call it at the start of the application. > > 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CACcVEiXvH3KnxaaonOkNmh1VsdQB7LbWKxFc25vvfFVw8nx2BQ%40mail.gmail.com.
