4 ms·
What do you usually look for after a trace? I know how to trace and I know the general gist of it in terms of looking at % ratio to see which function calls is
by rntksi 5y ago
What do you usually look for after a trace? I know how to trace and I know the general gist of it in terms of looking at % ratio to see which function calls is hogging the resources, but other than that I don't know what other insights one could infer from looking at a trace result.
Can you share your knowledge on this?
- p403n1x87 5y agoYou'd normally look at a more convenient visualisation of this data, usually in the form of a flame graph, which shows you aggregated figures for functions and the actual call stacks. If you don't care much about %'s you could still learn a lot about how a program works (especially if you're not familiar with it) just by looking at the call stacks. The VS Code extension makes this quite easy to do since you can click on the interactive flame graph to hop directly to the source code and peek around. See for example https://p403n1x87.github.io/how-to-bust-python-performance-issues.html https://p403n1x87.github.io/how-to-bust-python-performance-i..., which en passant shows you how pytest works internally
- omegalulw 5y agoNot OP but that is already a LOT of information. Usually you see which methods are hogging CPU which shouldn't, and optimize those. The nice part is that you can drill in at various levels of granularity. Really bleeding stuff would be stuff like minimizing copies and sharing memory within Kernels, vectorizing, etc.