On Sat, Oct 19, 2019 at 7:34 PM Nidhi Agrawal <nidhi11...@gmail.com> wrote:
>
> We don't need to set MemProfileRate. It is about block and mutex profiling 
> where we need to set the rate (SetBlockProfileRate, SetMutexProfileFraction) 
> at application start. Is there any performance impacts of doing that ?
>
> It is not causing any issue we want to enable block and mutex profiling so i 
> am thinking if we can do something like
>   SetBlockProfileRate(1)
>   pprof.Lookup("block").WriteTo(f, 0);
>   sleep(20)
>   SetBlockProfileRate(0)
> just like how cpu and trace profile works. But i am curious why isn't it not 
> already done in the library. What can be the reason behind this?
>
> I am curious why they are different from cpu and trace profiling, trying to 
> understand the inner working of this. It would be really helpful if you can 
> give me some pointers on where i can read about the high level design of the 
> pprof.

Oh, sorry, I misread what you were asking.  But now I'm not sure what
you are asking.  You said

> On the other hand for mutex and block profiling, it expects us to set the 
> rate at the start of the application and while calling profiling, it just 
> gathers the information and return.

That's how memory profiling works.  You don't have to set the mutex
and profiling rates at the start of the application.  You can set them
when you want to start profiling, as you suggest.  Is there some
documentation that says otherwise?

Sorry, I don't know of any documentation describing the profiling
implementation.

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/CAOyqgcWJWL234hQ1DW8PWMGuiQ%3D0SF-3sjcAxw%3DizGt%3D6uQnxg%40mail.gmail.com.

Reply via email to