3 ms·
>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
by pageald 9y 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.
- masklinn 9y ago> I can't comment on Ruby's profiling stack, but I think that cProfile is a great tool for finding bottlenecks in Python. 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)
- barrkel 9y agoGeneral rule I have: sampling profilers for CPU performance, instrumenting profilers for memory and other uses, like analyzing control flow.