|
|
|
|
|
|
by pageald
3117 days ago
|
|
|
>I’ll be on sabbatical from my job. . . and working on building better profiling tools for Ruby (and maybe Python??). I can't comment on Ruby's profiling stack, but I think that cProfile is a great tool for finding bottlenecks in Python. Usually, I've found that sorting functions by cumulative execution time is sufficient. You can't do flame graphs out-of-the-box, however. |
|
|
Whereas I don't. Between the performance impact (code with and without cprofile can have very different… profile), the lack of stack information and yet the lack of precise, actionable code-level information makes it not really useful/convenient for non-trivial codebases. Feeding the trace files to more visual systems (e.g. gprof2dot or runsnakerun) doesn't help much either.
These days I tend to use python-flamegraph (or pyflame but that's linux-only, though it has the advantage of using ptrace and can be attached to a running process at any point), this gives a mile-high view of the entire software in an extremely readable format, and from there it's possible to dive into specific hotspots with limited-scope profiles (whether with cprofile, with line_profiler[0] or with dedicated benchmarks).
[0] which has cprofile's issue of impacting the software it observes except significantly worse)