Evaluation of CPU profiling tools: gperftools, Valgrind and gprof (2015)
gernotklingler.com
Evaluation of CPU profiling tools: gperftools, Valgrind and gprof (2015)
1–10 of 29 posts
Re: Evaluation of CPU profiling tools: gperftools, Valgrind and gprof (2015)
#2The most interesting tool that I've found along these lines is sysdig.
The amount of different ways and the ease with which it can be used to dig in to and evaluate performance and other characteristics is truly awesome.
It can't do everything. But it can do a lot.
Re: Evaluation of CPU profiling tools: gperftools, Valgrind and gprof (2015)
#3Also worth mentioning here is perf[1], which is great for low overhead profiling. Also, perf profiles can be turned into profiles compatible with GCC and LLVM PGO to build optimized binaries based on production runs, using autofdo[2]. In my use case, the instrumentation overhead was too high to use regular profiling on production workloads.
Re: Evaluation of CPU profiling tools: gperftools, Valgrind and gprof (2015)
#4I absolutely love flamegraphs for analysing performance. If you haven't used one before and you're interested in optimization (in particular, of large programs you're unfamiliar with) then check them out! I also find them to be an easy way to get a grasp on complicated call stacks, since the addition of method linking on the call stacks makes it really easy to follow.
Re: Evaluation of CPU profiling tools: gperftools, Valgrind and gprof (2015)
#5Also worth mentioning here is perf[1], which is great for low overhead profiling. Also, perf profiles can be turned into profiles compatible with GCC and LLVM PGO to build optimized binaries based on production runs, using autofdo[2]. In my use case, the instrumentation overhead was too high to use regular profiling on production workloads. [1]: https://en.m.wikipedia.org/wiki/Perf_%28Linux%29 [2]: https://github.com…
Don't forget Hotspot as a way to visualize perf results, which vanilla perf is unfortunately a bit lacking in: https://github.com/KDAB/hotspot
Re: Evaluation of CPU profiling tools: gperftools, Valgrind and gprof (2015)
#6Also worth mentioning here is perf[1], which is great for low overhead profiling. Also, perf profiles can be turned into profiles compatible with GCC and LLVM PGO to build optimized binaries based on production runs, using autofdo[2]. In my use case, the instrumentation overhead was too high to use regular profiling on production workloads. [1]: https://en.m.wikipedia.org/wiki/Perf_%28Linux%29 [2]: https://github.com…
Don't forget Hotspot as a way to visualize perf results, which vanilla perf is unfortunately a bit lacking in: https://github.com/KDAB/hotspot
Thank you, I have been looking for something that could display perf recordings as a swimming lane view for threads.
Re: Evaluation of CPU profiling tools: gperftools, Valgrind and gprof (2015)
#7A problem with google perftools is the `SIGPROF` signal used in sampling will interrupt polling such as used in ZeroMQ. Otherwise, it is a good tool in the toolbox.
Re: Evaluation of CPU profiling tools: gperftools, Valgrind and gprof (2015)
#8Also worth considering is Oprofile: https://en.m.wikipedia.org/wiki/OProfile
Re: Evaluation of CPU profiling tools: gperftools, Valgrind and gprof (2015)
#9I'm just going to drop coz[1] as another suggestion. Ever since their talk/paper I expected other implementations of a causal profiler but for some reason everyone is steeped in the old ways. The concept just seems like such a huge efficiency boost compared to raw flame graphs. If you have time to watch their talk, it's linked on the github readme.
[1] https://github.com/plasma-umass/coz/blob/master/README.md
Re: Evaluation of CPU profiling tools: gperftools, Valgrind and gprof (2015)
#10I'm just going to drop coz[1] as another suggestion. Ever since their talk/paper I expected other implementations of a causal profiler but for some reason everyone is steeped in the old ways. The concept just seems like such a huge efficiency boost compared to raw flame graphs. If you have time to watch their talk, it's linked on the github readme. [1] https://github.com/plasma-umass/coz/blob/master/README.md
coz requires the user to instrument the code. So it's interesting but also much more costly to run experiments with.
I suspect it's cheaper to start with callgring to get an idea of the hot spots in the code base, find the low hanging fruits. Then switch to coz if you really need to squeeze out the last performance juice.