Ok, Thanks. On Mon, Oct 21, 2019 at 5:42 PM Ian Lance Taylor <i...@golang.org> wrote:
> On Mon, Oct 21, 2019 at 4:38 AM Nidhi Agrawal <nidhi11...@gmail.com> > wrote: > > > > Ok, Also is there any harm if we set block/mutex rate at the start of > the program ? Will it cause any memory allocations or any kind of > performance impact? > > It will cause some additional memory allocations as the program > records profiling information. But it won't be all that much memory. > The other performance impact should be minimal. > > Ian > > > > On Mon, Oct 21, 2019 at 2:47 PM Ian Lance Taylor <i...@golang.org> > wrote: > >> > >> On Sun, Oct 20, 2019 at 8:57 PM Nidhi Agrawal <nidhi11...@gmail.com> > wrote: > >> > > >> > 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 > supposed to set the rate. > >> > >> Yes, that is true. CPU profiling start with pprof.StartCPUProfile, > >> while block and mutex profiling start with runtime.SetBlockProfilerate > >> and runtime.SetMutexProfileFraction. But you don't have to set the > >> block and mutex rate at the start of the program. You set it when you > >> want to start profiling. > >> > >> You can also change the CPU profile rate with > >> runtime.SetCPUProfileRate, but that is hard to use without > >> pprof.StartCPUProfile. > >> > >> Ian > >> > >> > >> > On Sun, Oct 20, 2019 at 1:27 PM Ian Lance Taylor <i...@golang.org> > wrote: > >> >> > >> >> On Sun, Oct 20, 2019 at 12:51 AM Nidhi Agrawal <nidhi11...@gmail.com> > 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 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. > >> >> > >> >> I'm sorry, I don't really understand what you mean. > >> >> > >> >> There is really no difference among CPU, block, and mutex profiling > >> >> with regard to how they are used. In all cases you start profiling, > >> >> do some work, and then fetch the profile. They are all more or less > >> >> the same. I don't understand what is leading you to conclude that > >> >> they are different. > >> >> > >> >> Heap profiling, on the other hand, really is different, and it is > >> >> documented differently in runtime/pprof. > >> >> > >> >> Ian > >> >> > >> >> > >> >> > 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/CACcVEiUvr3oqpVOP5cVD1oSQqtXH6oveefgo5COXn432D5hExQ%40mail.gmail.com.
