3

pprof cpu profile

The pprof cpu profile shows user code (on the left) and code from the runtime package with their consumption of cpu time. I am wondering whether it is possible to make the connection between the two except for looking at the user code, changing it, profiling again, etc. - in a perfect world a tool would show me the lines in the user code that are responsible for runtime.allocSpan to be called.

What would be the fastest way to find the lines of code in the user code that are responsible?

larsbeck
  • 665
  • 2
  • 7
  • 11
  • Afaict this is logic that gets triggered whenever you do heap allocations and it checks whether it needs to fetch more pages from the OS. Thus I don't a single allocation "call" is the problem but just the general amount of allocations. I would try running with heap allocation profiling and check whether you can reduce the number of allocs. – ZeissS Jul 23 '23 at 11:21

1 Answers1

0

the same run under linux/amd64

This graph was generated with the same code being run. The difference is that the graph in the question was generated on darwin/arm64 and this one here was generated on linux/amd64. I expected a graph like this one where it is clear to see which piece of the user code is responsible. So the fact that the graph in the question looks different is either due to the OS or the architecture. We'll run some more experiments to see which of the two it is and if a dev container can help if you are trying to get this nicer looking profile on darwin/arm64 host as well.

Edit: The good news is that running a dev container on darwin/arm64 did the trick. We now get a nice looking pprof as expected.

larsbeck
  • 665
  • 2
  • 7
  • 11