On Fri, Oct 18, 2019 at 11:03 PM Nidhi Agrawal <nidhi11...@gmail.com> wrote:
>
> Golang runtime profiler (for cpu & trace) gives us an option to decide the
> time of profiling. It then sets the rate of profiling at start of the call
> and reset the rate at the end of the call. So it goes like this
>
> CPUProfiling() {
> StartCPUProfile() // internally calls SetCPUProfileRate(100)
> sleep(seconds)
> StopCPUProfile () // internally calls SetCPUProfileRate(0)
> }
>
> 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.
> My doubt is why mutex and block profiling have different behaviour ? Here
> also we could have set the rate at call start and reset at call end with some
> sleep time.
The two kinds of profiling work differently. Memory profiling is
based on sampling allocations as determined by runtime.MemProfileRate.
Adjusting that on the fly won't give you reasonable results, because
of how the profiling tools handle the data. Changing this would
require some mechanism to tell the tools when MemProfileRate changes,
and we don't have a way to do that.
Is this causing a problem?
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/CAOyqgcUjuj5fiE_WiQKTJ9MyiHCtAihrT4Y884M0thXA91Vh2A%40mail.gmail.com.
