[1] https://github.com/plasma-umass/coz/blob/master/README.md
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.
In a flame graph the width of a stack frame correlates to the % of CPU time spent in that stack frame, and the y is the particular call stack.
This means that you can quickly tell what functions, and from what call sites, are the most expensive.
The only visualization I know of that matches the ability to quickly zero in on things, while maintaining context, is a graph of call stack with frames colored by cumulative CPU time, but that has the issue that laying out the graph is hard, and seeing everything at once is difficult.
https://web.archive.org/web/20160718172225/http://gernotklin...
27 SIGPROF terminate process profiling timer alarm (see setitimer(2))
Additionally, it seems fixed in zeroMQ for some things already in 2016... so i doubt thats still valid issue.
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.
So I use "perf stat" now. :)
gcc -fsanitize=address ...
gcc -fsanitize=thread ...
Sanitizers and memcheck are unrelated to the profiling discussion here.