Today I learned you could do: `go build -gcflags="-m -m"` to get escape analysis information.
-
Today I learned you could do: `go build -gcflags="-m -m"` to get escape analysis information.
Is this what people commonly use in performance work when writing functions? Is there a better way? Is there a rough guide people follow?
I've never been great at memory management related things or performance engineering so trying to brush up a bit.
-
Today I learned you could do: `go build -gcflags="-m -m"` to get escape analysis information.
Is this what people commonly use in performance work when writing functions? Is there a better way? Is there a rough guide people follow?
I've never been great at memory management related things or performance engineering so trying to brush up a bit.
@purpleidea I’ll be interested in answers to this question. If my code has memory issues I generally use pprof to identify problematic functions.
-
@purpleidea I’ll be interested in answers to this question. If my code has memory issues I generally use pprof to identify problematic functions.
@imclaren I've definitely being using pprof, but I'm still feeling quite novice at it for now. Trying to figure out if it "just doesn't get any better" and there's an even better way to do this kind of analysis or if it's mostly just a lack of experience and you kind of need to be in the "in circle" to know the tricks.
-
Today I learned you could do: `go build -gcflags="-m -m"` to get escape analysis information.
Is this what people commonly use in performance work when writing functions? Is there a better way? Is there a rough guide people follow?
I've never been great at memory management related things or performance engineering so trying to brush up a bit.
@purpleidea If I have a function where I care about stuff not escaping (say, something that parses a string), I use this, yes.
For performance in general, I use pprof. Mostly CPU, as that often gives low-hanging fruit for algorithmic improvements. If it points at `runtime.growslice/memalloc/…` as a bottleneck, I might use the memory profile to find allocations (and then *might* use -gcflags=-m to eliminate some).
-m -m can also help making functions more inlinable, but that's the long tail. -
@purpleidea If I have a function where I care about stuff not escaping (say, something that parses a string), I use this, yes.
For performance in general, I use pprof. Mostly CPU, as that often gives low-hanging fruit for algorithmic improvements. If it points at `runtime.growslice/memalloc/…` as a bottleneck, I might use the memory profile to find allocations (and then *might* use -gcflags=-m to eliminate some).
-m -m can also help making functions more inlinable, but that's the long tail.@purpleidea For real *real* micro-optimization (which I only really do when being overly competitive for Advent of Code) I might look at the generated assembly for instructions and calls that I assumed would have been optimized out.
-
@purpleidea For real *real* micro-optimization (which I only really do when being overly competitive for Advent of Code) I might look at the generated assembly for instructions and calls that I assumed would have been optimized out.
@purpleidea My next life goal is to learn to use Linux perf to find bottlenecks in branch prediction and the page cache and the like ^^
-
@purpleidea If I have a function where I care about stuff not escaping (say, something that parses a string), I use this, yes.
For performance in general, I use pprof. Mostly CPU, as that often gives low-hanging fruit for algorithmic improvements. If it points at `runtime.growslice/memalloc/…` as a bottleneck, I might use the memory profile to find allocations (and then *might* use -gcflags=-m to eliminate some).
-m -m can also help making functions more inlinable, but that's the long tail.@Merovius Very helpful, thanks! But you've had good insight into a key part of my question:
When seeing all those internal functions in pprof (eg: runtime.* etc) short of guessing or assuming, where's the good guide that decodes the list of what you see there that's internal, to map that to reality and changes in my code?
I've seen a lot of functions that I don't know by heart and haven't read the code yet. Eg: lots of likely goroutine related scheduling and so on...
-
@Merovius Very helpful, thanks! But you've had good insight into a key part of my question:
When seeing all those internal functions in pprof (eg: runtime.* etc) short of guessing or assuming, where's the good guide that decodes the list of what you see there that's internal, to map that to reality and changes in my code?
I've seen a lot of functions that I don't know by heart and haven't read the code yet. Eg: lots of likely goroutine related scheduling and so on...
@purpleidea Not sure. So far, guessing was enough for me, together with looking for red lines in the code listing in the -http pprof view (for CPU and/or memory profiles) got me far enough.
I'm not writing *extremely* performance sensitive code, though. -
@purpleidea Not sure. So far, guessing was enough for me, together with looking for red lines in the code listing in the -http pprof view (for CPU and/or memory profiles) got me far enough.
I'm not writing *extremely* performance sensitive code, though.@Merovius Fair enough, me either! I'm definitely not going to the assembly level of things, but getting a rough idea of what's happening and learning how to fix those things is my currently goal. Making progress so far!
-
Today I learned you could do: `go build -gcflags="-m -m"` to get escape analysis information.
Is this what people commonly use in performance work when writing functions? Is there a better way? Is there a rough guide people follow?
I've never been great at memory management related things or performance engineering so trying to brush up a bit.
@purpleidea I have used that to understand why a given line is triggering allocation which I see is expensive from pprof. I think it is good tool to understand how the language works but not so useful in specific performance tuning runs.
Allocs put pressure on the GC and minimizing them definitely results in higher thruput for a given deployment size. I start with the profiler and then go from there. 1/2
-
@purpleidea I have used that to understand why a given line is triggering allocation which I see is expensive from pprof. I think it is good tool to understand how the language works but not so useful in specific performance tuning runs.
Allocs put pressure on the GC and minimizing them definitely results in higher thruput for a given deployment size. I start with the profiler and then go from there. 1/2
@purpleidea 2/2 My bete noir is always logging local variables that would otherwise be stack allocated thru a logging go routine which means they have to be on the heap. Expensive but I like my logging. And anyways I am using gRPC libraries that do a lot more allocs per request than my logging so it seems to be ok, but yeah I learned a lot from the escape analysis.
-
@imclaren I've definitely being using pprof, but I'm still feeling quite novice at it for now. Trying to figure out if it "just doesn't get any better" and there's an even better way to do this kind of analysis or if it's mostly just a lack of experience and you kind of need to be in the "in circle" to know the tricks.
@purpleidea yes I think there’s something to that. I generally use the flame graph / visual output to identify outliers and triage from there.
I find pprof deeply unintuitive. It would be wonderful to be able to import a library to the server which takes the pprof output and points you towards the likely culprit. Or is a kitchen sink analysis that shows all the pprof output in a comprehensive way.
-
@purpleidea yes I think there’s something to that. I generally use the flame graph / visual output to identify outliers and triage from there.
I find pprof deeply unintuitive. It would be wonderful to be able to import a library to the server which takes the pprof output and points you towards the likely culprit. Or is a kitchen sink analysis that shows all the pprof output in a comprehensive way.
@purpleidea usually the problem is a memory leak, too many goroutines, storing data in a slice or map and never clearing it (i. e. another memory leak), etc. It would be wonderful if pprof could point us to these issues and the related buggy code file and line number
-
R relay@relay.infosec.exchange shared this topic
