Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Profiling Go Applications with Flamegraphs

brendanjryan.com

Post reply on HN
Print view View original

21–28 of 28 posts

Re: Profiling Go Applications with Flamegraphs

#21

Post by flashmob »

Buge wrote: post #19

Does anyone else have this problem with go indentation: func (sc *SimpleClient) Timing(s string, d time.Duration, sampleRate float64, tags map[string]string) error { return sc.send([...] The wrapped parameter list is indented to the same level as the function body. Is this how it's supposed to be done?

No problem with that indenting here (personal opinion), I guess makes it easier to read if your editor doesn't have soft-wraps. However, generally, if the parameters list overflow to another line like that, it becomes a good candidate for refactoring!

Re: Profiling Go Applications with Flamegraphs

#22

Post by LaFolle »

Flamegraphs are good for CPU profiling (as far as I've used them), I've used them to debug an issue when one of our programs was "consistently" consuming high CPU. As the "stack" was mostly on CPU, during sampling, this stack was picked up most of the time, hence in flamegraphs, it was represented with a relatively longer bar.

But do they help to debug issues related to CPU spikes? I have my reservations because they are generated using sampling, and flamegraphs won't give a clear insight into who is causing the spikes.

Re: Profiling Go Applications with Flamegraphs

#23

Post by LaFolle »

LaFolle wrote: post #22

Flamegraphs are good for CPU profiling (as far as I've used them), I've used them to debug an issue when one of our programs was "consistently" consuming high CPU. As the "stack" was mostly on CPU, during sampling, this stack was picked up most of the time, hence in flamegraphs, it was represented with a relatively longer bar. But do they help to debug issues related to CPU spikes? I have my reservations because they…

One way to solve this I can think of is, if cpu spikes are deterministic, then we can take 2 profiles: 1. span consisting of no spikes 2. span consisting of at least 1 spike

And then "diff" them to get stack causing spikes.

Is this the correct way?

In general, how do people solve CPU spikes issue?

Re: Profiling Go Applications with Flamegraphs

#24

Post by oneweekwonder »

Whenever I see something like this I think of the 2015 video netflix[0] gave also using flamegraphs but for node.

Personally I want something like this for py.

In searching for the vid I see netflix also have a medium post(2014)[1] about it.

[0]: https://www.youtube.com/watch?v=O1YP8QP9gLA

[1]: https://medium.com/netflix-techblog/node-js-in-flames-ddd073...

Re: Profiling Go Applications with Flamegraphs

#25

Post by table-delete »

adamkl wrote: post #3
ronnier wrote: post #2

I’m trying to figure out why I find Go so hard to read. Am I mostly alone with this?

It’s considered idiomatic in Go to use very short variable names [1], which seems masochistic to me. Every time I look at Go code, it’s like I’m back in high school using Borland Turbo C all over again. [1] https://github.com/golang/go/wiki/CodeReviewComments#variabl...

There's a great rule of thumb coined by Andrew Gerrand: "The greater the distance between a name's declaration and its uses, the longer the name should be." [1]

There's no reason to use any more than a single character for a loop variable. Who cares how old the convention is?

[1] https://talks.golang.org/2014/names.slide

Re: Profiling Go Applications with Flamegraphs

#26

Post by farnsworthy »

flashmob wrote: post #21
Buge wrote: post #19

Does anyone else have this problem with go indentation: func (sc *SimpleClient) Timing(s string, d time.Duration, sampleRate float64, tags map[string]string) error { return sc.send([...] The wrapped parameter list is indented to the same level as the function body. Is this how it's supposed to be done?

No problem with that indenting here (personal opinion), I guess makes it easier to read if your editor doesn't have soft-wraps. However, generally, if the parameters list overflow to another line like that, it becomes a good candidate for refactoring!

Yeah, it could be a new struct, especially if another parameter or two comes along (though the simplest thing has its benefits, too).

Re: Profiling Go Applications with Flamegraphs

#27

Post by zxcmx »

nahname wrote: post #10
carbocation wrote: post #8

Earlier quoted context omitted.

I've mostly interpreted that to use single character names for method receivers and loop variables. I think those are defensible because you know where to find them if you need their definition (in the method definition or in the loop). I don't think that assigning terse names (such as the variable "ra" from the OP) to variables that might be declared anywhere in a function is helpful.

Though that would still be idiomatic go code. For what it is worth, I do agree with you. Short variable names on a function are a hassle. You have to lookup what they mean, which slows down understanding. n = copy(p, b.buf[b.r:b.w]) Oh better go to the top and see what those are again... https://github.com/golang/go/blob/master/src/bufio/bufio.go#...

I didn't look at the file but I find that perfectly comprehensible. I can see read & write pointers in a buffer, n as bytes copied. Not sure if p is source or dest w/out looking but my guess is dest?

Maybe it's a cultural thing - lots of C code looks like this from Lion's UNIX book onwards. I still find this style easier on the eyes when it's clear from context what is going on.

For i/o code this is about as obscure as using "i" for a loop index.

Re: Profiling Go Applications with Flamegraphs

#28

Post by gnufx »

How are flame graphs a better way of displaying profile data than viewers like paraprof [1] or cube [2], which have tree/flat and inclusive/exclusive views, as opposed to essentially just an inclusive tree view? Consider seeing the effect of something called all over the place in a complex system.

[1] http://www.vi-hps.org/upload/material/tw-score-p/vi-hps-tw-s... [2] http://www.vi-hps.org/upload/material/tw-score-p/vi-hps-tw-s...

Post reply on HN