> Recently however I've started using sampling profilers and flamegraph representations[0]
Maybe you should take a closer look at what pprof does and not draw conclusions only from Python's line_profiler. Go's profiler doesn't have flamegraphs, but it has directed graphs. Here's an example:
As you can see, it is very easy to see the bottlenecks. In fact the first thing I always do when profiling is outputting this svg to have a good first view of what's happening.
pprof is a "global" whole-program profilers, so you don't need to care about what line to profile or not. My only limitation for the moment is that you can't dive in cgo code.
> Maybe you should take a closer look at what pprof does and not draw conclusions only from Python's line_profiler. Go's profiler doesn't have flamegraphs, but it has directed graphs.
Python profilers have directed graph representations, they are little better than the normal textual output.
> As you can see, it is very easy to see the bottlenecks.
With trivial programs, the most terrible representations are no issue. Cycles in callstacks (partial mutual recursion) or "hot nodes" (dispatcher code) completely break directed graph output, but not flamegraphs.
Maybe you should take a closer look at what pprof does and not draw conclusions only from Python's line_profiler. Go's profiler doesn't have flamegraphs, but it has directed graphs. Here's an example:
https://rawgit.com/benbjohnson/5b4fb2ffb6874484e586/raw/60af...
As you can see, it is very easy to see the bottlenecks. In fact the first thing I always do when profiling is outputting this svg to have a good first view of what's happening.
pprof is a "global" whole-program profilers, so you don't need to care about what line to profile or not. My only limitation for the moment is that you can't dive in cgo code.